9 p.m.
Andy, others,
There seems to be some problems with the synced semantic package, I
found at least these:
A number of files seems to be missing (semantic-cb.el,
semantic-chart.el). I'm not sure if Makefile (ELCS) is up to date
either, at least it mentions -cb.el though we don't have the file.
package-info.in hasn't been updated to match all provides.
Possibly a bigger problem, the home page at
<http://cedet.sourceforge.net/semantic.shtml> says that semantic 1.4
requires speedbar 0.14 beta 3 (or latest -beta 4, we have 0.13) and
latest eieio (0.17beta4?, we have 0.16).
To me it seems that the upgrade should not have been made until we can
update all Eric's tools + possibly JDE at the same time.
Andy, what do you think?
--
\/ille Skyttä
ville.skytta at xemacs.org
9:12 p.m.
At 11:00 PM 8/6/2002 +0300, Ville Skyttä wrote:
Possibly a bigger problem, the home page at
<http://cedet.sourceforge.net/semantic.shtml> says that semantic 1.4
requires speedbar 0.14 beta 3 (or latest -beta 4, we have 0.13) and
latest eieio (0.17beta4?, we have 0.16).
To me it seems that the upgrade should not have been made until we can
update all Eric's tools + possibly JDE at the same time.
Andy, what do you think?
Yeah, that's probably right. These packages are all so horribly intertwined
that doing a single update is problematic.
I'll submit everything I have. It all works pretty well for me.
andy
9:29 p.m.
On Tue, 2002-08-06 at 23:12, Andy Piper wrote:
>To me it seems that the upgrade should not have been made until
we can
>update all Eric's tools + possibly JDE at the same time.
>
>Andy, what do you think?
Yeah, that's probably right. These packages are all so horribly intertwined
that doing a single update is problematic.
Yeah, I have that feeling too...
I'll submit everything I have. It all works pretty well for me.
I'm not sure if that would be a good idea.
Or is there a real requirement that they should be updated now, instead
of updating all of them when there's a new *stable* upstream version of
them available?
--
\/ille Skyttä
ville.skytta at xemacs.org
9:36 p.m.
At 11:29 PM 8/6/2002 +0300, Ville Skyttä wrote:
I'm not sure if that would be a good idea.
Or is there a real requirement that they should be updated now, instead
of updating all of them when there's a new *stable* upstream version of
them available?
It depends how you define stable. The combined new packages work better for
me than the current "stable" versions.
andy
9:47 p.m.
On Tue, 2002-08-06 at 23:36, Andy Piper wrote:
>I'm not sure if that would be a good idea.
>
>Or is there a real requirement that they should be updated now, instead
>of updating all of them when there's a new *stable* upstream version of
>them available?
It depends how you define stable. The combined new packages work better for
me than the current "stable" versions.
Okay, that's a valid reason. What about the speedbar upgrade, do you
know if it introduces incompatibilities? prog-modes, xslt-process and
vhdl require it (in addition, xslt-process requires eieio, semantic and
jde).
--
\/ille Skyttä
ville.skytta at xemacs.org
9:48 p.m.
At 11:47 PM 8/6/2002 +0300, Ville Skyttä wrote:
Okay, that's a valid reason. What about the speedbar upgrade, do
you
know if it introduces incompatibilities? prog-modes, xslt-process and
vhdl require it (in addition, xslt-process requires eieio, semantic and
jde).
Hmmn, I see. I guess we could hope that they are backwardsly compatible but
who knows. I can test speedbar with other things, I've no idea how to test
xslt stuff.
andy
10:01 p.m.
On Tue, 2002-08-06 at 23:48, Andy Piper wrote:
>Okay, that's a valid reason. What about the speedbar
upgrade, do you
>know if it introduces incompatibilities? prog-modes, xslt-process and
>vhdl require it (in addition, xslt-process requires eieio, semantic and
>jde).
Hmmn, I see. I guess we could hope that they are backwardsly compatible but
who knows. I can test speedbar with other things, I've no idea how to test
xslt stuff.
Ovidiu, we're talking about possibly upgrading jde, eieio, speedbar and
semantic to their latest versions in XEmacs. Do you know if
xslt-process will work with them?
Oh, and we still have xslt-process 1.2.1. Wouldn't it make sense to
upgrade it to a newer version, I see 2.1 is the current one. Of course,
2.1 would have to be stripped down quite a bit, 6MB+ gzipped is IMHO a
bit much for a single XEmacs package... :)
--
\/ille Skyttä
ville.skytta at xemacs.org
7:30 a.m.
Hi Ville,
Sorry for replying so late, your message got lost in a ton of others.
On 8/6/02 2:01 PM, "Ville Skyttä" <ville.skytta(a)xemacs.org> wrote:
On Tue, 2002-08-06 at 23:48, Andy Piper wrote:
>> Okay, that's a valid reason. What about the speedbar upgrade, do you
>> know if it introduces incompatibilities? prog-modes, xslt-process and
>> vhdl require it (in addition, xslt-process requires eieio, semantic and
>> jde).
>
> Hmmn, I see. I guess we could hope that they are backwardsly compatible but
> who knows. I can test speedbar with other things, I've no idea how to test
> xslt stuff.
Ovidiu, we're talking about possibly upgrading jde, eieio, speedbar and
semantic to their latest versions in XEmacs. Do you know if
xslt-process will work with them?
I think with 2.1 I already use the latest eieio, speedbar and semantic, but
I'll make sure it does work.
Oh, and we still have xslt-process 1.2.1. Wouldn't it make sense
to
upgrade it to a newer version, I see 2.1 is the current one. Of course,
2.1 would have to be stripped down quite a bit, 6MB+ gzipped is IMHO a
bit much for a single XEmacs package... :)
The size of the package also made me stay away from upgrading the Xemacs
version:) Steve suggested I could have a minimal package and then allow
users to download the rest of the bits on demand.
I was thinking what would be the best way to do this, to avoid security
issues as well. Is there an Xemacs way to cryptographically sign files,
which is independent on external packages like gpg or pgp? Or should I rely
instead on Java security?
Regards,
--
Ovidiu Predescu <ovidiu(a)apache.org>
http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
7:52 p.m.
On Mon, 2002-08-12 at 09:30, Ovidiu Predescu wrote:
Hi Ville,
Sorry for replying so late, your message got lost in a ton of others.
No problem!
> Ovidiu, we're talking about possibly upgrading jde, eieio,
speedbar and
> semantic to their latest versions in XEmacs. Do you know if
> xslt-process will work with them?
I think with 2.1 I already use the latest eieio, speedbar and semantic, but
I'll make sure it does work.
Cool.
> Oh, and we still have xslt-process 1.2.1. Wouldn't it make
sense to
> upgrade it to a newer version, I see 2.1 is the current one. Of course,
> 2.1 would have to be stripped down quite a bit, 6MB+ gzipped is IMHO a
> bit much for a single XEmacs package... :)
The size of the package also made me stay away from upgrading the Xemacs
version:) Steve suggested I could have a minimal package and then allow
users to download the rest of the bits on demand.
Yes, sounds sensible to me too.
I was thinking what would be the best way to do this, to avoid
security
issues as well. Is there an Xemacs way to cryptographically sign files,
which is independent on external packages like gpg or pgp? Or should I rely
instead on Java security?
Hmm, the mailcrypt package? But it needs pgp/gpg... is that a problem?
xslt-process could always require mailcrypt in XEmacs. What files are
you planning to sign?
--
\/ille Skyttä
ville.skytta at xemacs.org
8:54 p.m.
On 8/12/02 11:52 AM, "Ville Skyttä" <ville.skytta(a)xemacs.org> wrote:
> The size of the package also made me stay away from upgrading the
Xemacs
> version:) Steve suggested I could have a minimal package and then allow
> users to download the rest of the bits on demand.
Yes, sounds sensible to me too.
> I was thinking what would be the best way to do this, to avoid security
> issues as well. Is there an Xemacs way to cryptographically sign files,
> which is independent on external packages like gpg or pgp? Or should I rely
> instead on Java security?
Hmm, the mailcrypt package? But it needs pgp/gpg... is that a problem?
xslt-process could always require mailcrypt in XEmacs. What files are
you planning to sign?
I was thinking to sign and authenticate the bits which get downloaded on
request, by the XSLT-process package. These are some Java jar files which
are not essential to the core functionality of the package, but are needed
to enable certain functionality.
I'll take a look at mailcrypt.
Regards,
Ovidiu
9:44 p.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> On Mon, 2002-08-12 at 09:30, Ovidiu Predescu wrote:
>I was thinking what would be the best way to do this, to avoid
security
>issues as well. Is there an Xemacs way to cryptographically sign files,
>which is independent on external packages like gpg or pgp? Or should I
>rely instead on Java security?
VS> Hmm, the mailcrypt package? But it needs pgp/gpg... is that a
VS> problem? xslt-process could always require mailcrypt in XEmacs.
Hi Ovidiu!
We've just added a new package to XEmacs called "ecrypto", this sounds
like something it could handle. It hasn't been released in the
mainline packages yet, but it is in Pre-Release.
Check it out...
/ftp.xemacs.org:/pub/xemacs/beta/experimental/packages/
HTH
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
8:53 a.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> On Mon, 2002-08-12 at 09:30, Ovidiu Predescu wrote:
>>I was thinking what would be the best way to do this, to avoid
security issues as well. Is there an Xemacs way to cryptographically
sign files, which is independent on external packages like gpg or
pgp? Or should I rely instead on Java security?
VS> Hmm, the mailcrypt package? But it needs pgp/gpg... is that a VS>
problem? xslt-process could always require mailcrypt in XEmacs.
Hi Ovidiu!
We've just added a new package to XEmacs called "ecrypto", this sounds
like something it could handle. It hasn't been released in the
mainline packages yet, but it is in Pre-Release.
That package only contains low-level functions, I don't think you can
digitally sign anything in a useful way using that code. I think this
really must be designed into the package system itself -- packages should
be signed, and the package installer should verify it against a XEmacs
Release Manager certificate. This is how RPM do it.
Mailcrypt has the required functionality though. And GPG or OpenSSL will
be needed unless we want to implement OpenPGP/PKIX in elisp.
10:05 a.m.
On 8/13/02 12:53 AM, "Simon Josefsson" <jas(a)extundo.com> wrote:
> |--==> "VS" == Ville Skytt <Ville> writes:
>
> VS> On Mon, 2002-08-12 at 09:30, Ovidiu Predescu wrote:
>>> I was thinking what would be the best way to do this, to avoid
> security issues as well. Is there an Xemacs way to cryptographically
> sign files, which is independent on external packages like gpg or
> pgp? Or should I rely instead on Java security?
>
> VS> Hmm, the mailcrypt package? But it needs pgp/gpg... is that a VS>
> problem? xslt-process could always require mailcrypt in XEmacs.
>
> Hi Ovidiu!
>
> We've just added a new package to XEmacs called "ecrypto", this sounds
> like something it could handle. It hasn't been released in the
> mainline packages yet, but it is in Pre-Release.
That package only contains low-level functions, I don't think you can
digitally sign anything in a useful way using that code. I think this
really must be designed into the package system itself -- packages should
be signed, and the package installer should verify it against a XEmacs
Release Manager certificate. This is how RPM do it.
Mailcrypt has the required functionality though. And GPG or OpenSSL will
be needed unless we want to implement OpenPGP/PKIX in elisp.
You're right on the issue! I've described the situation few minutes ago
exactly the same way on my Weblog, at
http://www.webweavertech.com/ovidiu/weblog/archives/000023.html
I think Xemacs needs to have cryptographically signed packages by default on
its main site. Right now we don't do any check to verify the authenticity of
the packages, and a malicious hacker might easily change the packages. A
similar problem was recently reported at Apple, their software update
procedure was not cryptographically signing the distributed packages. Here
is a description of the attack:
http://www.cunap.com/~hardingr/projects/osx/exploit.html
For now I think I'll look into using either mailcrypt or the Java stuff, if
it's possible.
Regards,
--
Ovidiu Predescu <ovidiu(a)xemacs.org>
http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
10:39 a.m.
You're right on the issue! I've described the situation few
minutes ago
exactly the same way on my Weblog, at
http://www.webweavertech.com/ovidiu/weblog/archives/000023.html
I think Xemacs needs to have cryptographically signed packages by
default on its main site. Right now we don't do any check to verify the
authenticity of the packages, and a malicious hacker might easily change
the packages.
XEmacs isn't alone, Debian doesn't have signed packages either.
I think it would be nice if this worked, but IMHO this isn't an immediate
problem. It should be added slowly so it doesn't cause problems for
users. If it causes problems, people will dislike it regardless of its
merits.
11:33 a.m.
>> On 2002-08-13 02:05:11 -0700, Ovidiu Predescu
<ovidiu(a)xemacs.org> said:
>> On 2002-08-13 11:39:44 +0200, "Simon Josefsson" <jas(a)extundo.com>
said:
OP> I think Xemacs needs to have cryptographically signed packages
OP> by default on its main site. Right now we don't do any check to
OP> verify the authenticity of the packages, and a malicious hacker
OP> might easily change the packages.
SJ> XEmacs isn't alone, Debian doesn't have signed packages either.
For some version of signed. When a package is uploaded to the Debian
master repository, it does have to be signed by a developer - and the
developer has to have met and exchanged keys with another of the Debian
developers to have their identity trusted. The packages file is signed,
and contains md5sums of the .debs. The security is at the server end
rather than left to the individual client, but is verifiable via the
OpenPGP web of trust if a client wishes to do so.
This is identical to the RPM situation as already described, so to say
"Debian doesn't have signed packages either" in response to "Right now
we don't do any check to verify the authenticity of the packages", seems
misleading; Debian's packaging system does allow you to verify the
authenticity of packages and is no less secure in doing so than Red Hat.
Simon's statement is techically ccorrect, though - the .deb files are
not always signed. There's certainly facility for it, in the debsign(1)
command, but it isn't mandatory and the signature can be stripped from
the .deb non-fatally. Again, I believe this to be identical to Red
Hat's situation.
I imagine Debian went for this concentration on verifiable server-side
security rather than client-side checks for the same reasons the list is
reluctant about the switch; user impact. Perhaps it's a good plan for
XEmacs packaging too.
Hope this helps a little,
- Chris.
--
$a="printf.net"; Chris Ball | chris(a)void.$a | www.$a | finger: chris＠$a
11:03 a.m.
But hold on, that isn't only about securing XEmacs packages. A few $.2
reactions:
1) 6MB is not much. Who will complain about 6 more MB's? If people can't
afford to download 6MB, they don't have to, thanks to the packaging
system. IMHO, I wouldn't even worry about a 60MB package, should one
exist. Optimizing for size is a waste of time 99% of the time.
2) Why _are_ the JAR files included in XSLT XEmacs package in the first
place? Are they used as data files and parsed by Elisp code? In that
case, I'd say include them. No need to download them on the fly. If they
instead constitute an external Java application, it does not make sense to
include them nor download them. Lots of XEmacs packages requires external
applications -- splitting the XSLT package into the elisp part and the
Java part seems easier. The elisp part should document that it requires
the external Java part installed.
These problems seems orthogonal to securing XEmacs packages.
2:06 a.m.
>>>> "Ovidiu" == Ovidiu Predescu
<ovidiu(a)xemacs.org> writes:
Ovidiu> I think Xemacs needs to have cryptographically signed
Ovidiu> packages by default on its main site. Right now we don't
Ovidiu> do any check to verify the authenticity of the packages,
We have MD5 checksums available; MD5 failures are the most common
single package bug. This could easily (I think) be upgraded to
individual GPG signatures, and Steve did sign the checksum list.
Ovidiu> and a malicious hacker might easily change the packages.
Hell, Ovidiu, we don't know whether _you_ are a white hat or a black
hat. Or me, for that matter. (Dennis Ritchie is a confessed white
hat.) There are easier ways to suborn the packages than breaking
security on Tux or the maintainers' personal machines.
IMHO if someone worries enough about security that they worry about
XEmacs Lisp packages, they should not have an Emacs of any flavor
installed at all. We take some care with shells and things like that
to prevent echoing of passwords, but I regularly get cleartext when I
upgrade ssh or fiddle with my password prompt regexp. Other than that
simple service to users, Emacs is a security hole waiting to happen.
Hell, we've at least suggested massive security violations ourselves
(Steve Y once suggested automatically including init.el and custom.el
in the automatic bug report, for example). We do include the last 300
keystrokes automatically. Etc, etc.
That said, I don't disagree with signing the packages. But we should
make absolutely clear that this is a consistency check, not a serious
security measure.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
10:45 a.m.
Stephen,
On 8/13/02 6:06 PM, "Stephen J. Turnbull" <stephen(a)xemacs.org> wrote:
>>>>> "Ovidiu" == Ovidiu Predescu
<ovidiu(a)xemacs.org> writes:
Ovidiu> I think Xemacs needs to have cryptographically signed
Ovidiu> packages by default on its main site. Right now we don't
Ovidiu> do any check to verify the authenticity of the packages,
We have MD5 checksums available; MD5 failures are the most common
single package bug. This could easily (I think) be upgraded to
individual GPG signatures, and Steve did sign the checksum list.
I don't think the upgrade process is that easy. I'm not an expert, but
managing the public keys and all that, do require some management effort,
which translates into a non-zero amount of design and code.
Ovidiu> and a malicious hacker might easily change the
packages.
Hell, Ovidiu, we don't know whether _you_ are a white hat or a black
hat. Or me, for that matter. (Dennis Ritchie is a confessed white
hat.) There are easier ways to suborn the packages than breaking
security on Tux or the maintainers' personal machines.
I'm not worried about package authors, I worry about the bad guys modifying
legitimate package to run malicious code.
IMHO if someone worries enough about security that they worry about
XEmacs Lisp packages, they should not have an Emacs of any flavor
installed at all. We take some care with shells and things like that
to prevent echoing of passwords, but I regularly get cleartext when I
upgrade ssh or fiddle with my password prompt regexp. Other than that
simple service to users, Emacs is a security hole waiting to happen.
This is not good news. I think sooner or later, the bad guys will starting
hunting security bugs in Emacs, which is a fairly popular platform on
Unix/Linux. At the very least we should make sure we don¹t get fooled into
installing malicious packages, and have open sockets accepting connections
from the Internet.
Hell, we've at least suggested massive security violations
ourselves
(Steve Y once suggested automatically including init.el and custom.el
in the automatic bug report, for example). We do include the last 300
keystrokes automatically. Etc, etc.
That said, I don't disagree with signing the packages. But we should
make absolutely clear that this is a consistency check, not a serious
security measure.
Yes, I agree with you.
Best regards,
--
Ovidiu Predescu <ovidiu(a)xemacs.org>
http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
10:57 a.m.
New subject: Public key signing packages [was: Problems with new semantic package]
>>>> "Ovidiu" == Ovidiu Predescu
<ovidiu(a)xemacs.org> writes:
Ovidiu> I don't think the upgrade process is that easy. I'm not an
Ovidiu> expert, but managing the public keys and all that, do
Ovidiu> require some management effort, which translates into a
Ovidiu> non-zero amount of design and code.
I don't think it _requires_ any design or code, just that maintainers
have keys and publish them. Preferably with multiple signings on
public keyservers, of course. But all this is startup cost for
maintainers, anyway. We could provide a simple startup guide and
helper code, of course.
Eg, my tarballs are signed. This is not at all trustworthy since
those keys are not cross-signed by anybody. But it's just a couple of
lines in my build script, and it would be easy for me to generate new
keys, get them signed, etc., and away we go.
Ovidiu> I'm not worried about package authors, I worry about the
Ovidiu> bad guys modifying legitimate package to run malicious
Ovidiu> code.
Becoming a legitimate package author is the easiest way to do that.
Ovidiu> At the very least we should make sure we don¹t get fooled
Ovidiu> into installing malicious packages, and have open sockets
Ovidiu> accepting connections from the Internet.
Can't happen on XEmacs, yet: we don't have the "listen" socket code.
When we do, it should be done as an ELL, and we should find some way
to make that code unavailable without explicit operator intervention.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
1:22 p.m.
New subject: Public key signing packages [was: Problems with new semantic package]
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Ovidiu" == Ovidiu Predescu
<ovidiu(a)xemacs.org> writes:
Ovidiu> I don't think the upgrade process is that easy. I'm not an
Ovidiu> expert, but managing the public keys and all that, do
Ovidiu> require some management effort, which translates into a
Ovidiu> non-zero amount of design and code.
I don't think it _requires_ any design or code, just that maintainers
have keys and publish them.
The RedHat approach would be to simply have the XEmacs Package
Maintainer sign the packages. IMHO this will be Good Enough for quite
some time, at least compared to the alternatives.
Protecting against malicious uploads to the XEmacs CVS servers would
be the next step, but subtle philosophical problems would appear
quickly. Why would xemacs.org trust me to not include trojan's in
mail-lib? The only trust metric I can define that would work for
distributed free software projects is extrapolation of past behaviour,
but this isn't a robust metric. For someone with long term malicious
intent, sponsoring a free software developer for 5 years and then
having him include trojan's in some packages is cheap.
The Debian approach is more robust, requiring developers to meet in
person and sign each others keys. But it won't work if there are few
developers, and in reality just knowing who someone is doesn't prevent
that person from causing harm.
Fortunately, the threat to XEmacs is probably minuscale compared to
the various security server implementations. As long as OpenSSH and
OpenSSL is cracked every other month, attacking XEmacs is not relevant.
Let's hope they continue to be cracked, then. ;-)
1:40 p.m.
New subject: Public key signing packages [was: Problems with new semantic package]
>>>> "Simon" == Simon Josefsson
<jas(a)extundo.com> writes:
Simon> As long as OpenSSH and OpenSSL is cracked every other
Simon> month, attacking XEmacs is not relevant. Let's hope they
Simon> continue to be cracked, then. ;-)
Better yet, let's hope they gradually become harder and harder
targets, while Theo's arrogance remains unabated. That should keep
GOBBLES busy.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
My nostalgia for Icon makes me forget about any of the bad things. I don't
have much nostalgia for Perl, so its faults I remember. Scott Gilbert c.l.py
7:30 a.m.
Hi Ville,
Sorry for replying so late, your message got lost in a ton of others.
On 8/6/02 2:01 PM, "Ville Skyttä" <ville.skytta(a)xemacs.org> wrote:
On Tue, 2002-08-06 at 23:48, Andy Piper wrote:
>> Okay, that's a valid reason. What about the speedbar upgrade, do you
>> know if it introduces incompatibilities? prog-modes, xslt-process and
>> vhdl require it (in addition, xslt-process requires eieio, semantic and
>> jde).
>
> Hmmn, I see. I guess we could hope that they are backwardsly compatible but
> who knows. I can test speedbar with other things, I've no idea how to test
> xslt stuff.
Ovidiu, we're talking about possibly upgrading jde, eieio, speedbar and
semantic to their latest versions in XEmacs. Do you know if
xslt-process will work with them?
I think with 2.1 I already use the latest eieio, speedbar and semantic, but
I'll make sure it does work.
Oh, and we still have xslt-process 1.2.1. Wouldn't it make sense
to
upgrade it to a newer version, I see 2.1 is the current one. Of course,
2.1 would have to be stripped down quite a bit, 6MB+ gzipped is IMHO a
bit much for a single XEmacs package... :)
The size of the package also made me stay away from upgrading the Xemacs
version:) Steve suggested I could have a minimal package and then allow
users to download the rest of the bits on demand.
I was thinking what would be the best way to do this, to avoid security
issues as well. Is there an Xemacs way to cryptographically sign files,
which is independent on external packages like gpg or pgp? Or should I rely
instead on Java security?
Regards,
--
Ovidiu Predescu <ovidiu(a)apache.org>
http://www.webweavertech.com/ovidiu/weblog/index.html (Weblog)
http://www.geocities.com/SiliconValley/Monitor/7464/ (Apache, GNU, Emacs...)
10:10 p.m.
>>>> "andy" == Andy Piper <andyp(a)bea.com>
writes:
andy> At 11:29 PM 8/6/2002 +0300, Ville Skyttä wrote:
> I'm not sure if that would be a good idea.
>
> Or is there a real requirement that they should be updated now, instead
> of updating all of them when there's a new *stable* upstream version of
> them available?
andy> It depends how you define stable. The combined new packages work
andy> better for me than the current "stable" versions.
I would strongly agree with Andy, here. Also, they seem to be
required for ECB, which is extremely useful.
best,
-tony
--
A.J. Rossini Rsrch. Asst. Prof. of Biostatistics
U. of Washington Biostatistics rossini(a)u.washington.edu
FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org
-------------- http://software.biostat.washington.edu/ ----------------
FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email
UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX
(my tuesday/wednesday/friday locations are completely unpredictable.)
10:24 p.m.
On Wed, 2002-08-07 at 00:10, A.J. Rossini wrote:
>> Or is there a real requirement that they should be
updated now, instead
>> of updating all of them when there's a new *stable* upstream version of
>> them available?
andy> It depends how you define stable. The combined new packages work
andy> better for me than the current "stable" versions.
I would strongly agree with Andy, here. Also, they seem to be
required for ECB, which is extremely useful.
Yep, I'd like to try out ECB too (I have an initial version of a package
in unsupported/scop waiting for semantic to be updated).
But first we need to make sure that the _existing_ XEmacs packages work
after the upgrade...
--
\/ille Skyttä
ville.skytta at xemacs.org
2:39 p.m.
|--==> "VS" == Ville Skytt <Ville> writes:
VS> Andy, others,
VS> There seems to be some problems with the synced semantic package, I
Guys, we could get ourselves into all kinds of trouble here because
Semantic, Speedbar, EIEIO (and probably a few others) are all very
closely intertwined.
As I said in private email, give me a couple of days and I'll fix
everything up. Please don't submit/commit any patches concerning this
for a day or so.
Thanks people.
[ Just want to eliminate half a dozen people coming up with half a
dozen solutions to the same problem at the same time. ]
Ville, Peter, if you think I'm stepping on your toes, just yell and
I'll step back.
--
|---<Steve Youngs>---------------<GnuPG KeyID: 10D5C9C5>---|
| XEmacs - It's not just an editor. |
| It's a way of life. |
|------------------------------------<youngs(a)xemacs.org>---|
5:07 p.m.
At 11:39 PM 8/7/2002 +1000, Steve Youngs wrote:
Guys, we could get ourselves into all kinds of trouble here because
Semantic, Speedbar, EIEIO (and probably a few others) are all very
closely intertwined.
As I said in private email, give me a couple of days and I'll fix
everything up. Please don't submit/commit any patches concerning this
for a day or so.
What do you mean by fix? I have pending patches for all of these packages.
Please don't redo this work.
Thanks
andy
6:59 p.m.
>>>> "SY" == Steve Youngs
<youngs(a)xemacs.org> writes:
SY> |--==> "VS" == Ville Skytt <Ville> writes:
VS> Andy, others,
VS> There seems to be some problems with the synced semantic package, I
SY> Guys, we could get ourselves into all kinds of trouble here because
SY> Semantic, Speedbar, EIEIO (and probably a few others) are all very
SY> closely intertwined.
SY> As I said in private email, give me a couple of days and I'll fix
SY> everything up. Please don't submit/commit any patches concerning this
SY> for a day or so.
SY> Thanks people.
SY> [ Just want to eliminate half a dozen people coming up with half a
SY> dozen solutions to the same problem at the same time. ]
SY> Ville, Peter, if you think I'm stepping on your toes, just yell and
SY> I'll step back.
nope no toe stepping here :)
i dont think i could work out how to fix this with my current skill level
go for it dude
--
XEmacs Advocate | Do not try the patience of Wizards,
FreeBSD Devote | for they are subtle and quick to anger.
Perl Hacker | - Elric (Technomage) , Babylon 5.
Apache God | <mailto:rendhalver＠xemacs.org> <GnuPG KeyID: AE51D190>
7:25 p.m.
On Wed, 2002-08-07 at 20:59, Rendhalver [Peter Brown] wrote:
SY> Ville, Peter, if you think I'm stepping on your toes,
just yell and
SY> I'll step back.
nope no toe stepping here :)
Fine with me too. Thanks, Steve.
--
\/ille Skyttä
ville.skytta at xemacs.org
8131
days inactive
8139
days old
27 comments
10 participants
participants (10)
-
A.J. Rossini -
Andy Piper -
Chris Ball -
Ovidiu Predescu -
Ovidiu Predescu -
Rendhalver [Peter Brown] -
Simon Josefsson -
Stephen J. Turnbull -
Steve Youngs -
Ville Skyttä