Re: 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. ;-)