Re: Problems with new semantic package

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