Robert,
berin
therefore, it seems to me that a release signed by a key which resides on an ASF machine can be trusted as much as a release downloaded directly from an ASF machine.
so, in security terms, moving from unsigned releases on an ASF machine to signed releases on mirror with keys on ASF machines is security neutral.
moving to a secure apache wide system of signed keys would be a definite improvement. (but there may be practical problems to be overcome.)
Absolutely agree with all of the above. Thus my question about "what is the aim". If the aim is to remain in a neutral state, then OK. It just seems to me that given we have to address one problem, then there is an opportunity to address the wider problem and look at how we can overcome the practical problems you mention. They have all been overcome before, and anything that promotes "trust" in the Apache brand has to be a good thing?
+1
i think that it's important to understand the primary purpose behind the current key signing system is to allow mirrors to take the strain from daedelus without making security worse than it is at the moment. so, it's the positive 'promotion of trust' angle which is the one to take.
IMHO the main practical issue is that apache committers are on five continents. i've never met any other committers in person. getting all release managers together in a room where everyone can sign everyone else'
s (code signing) key is never going to happen.
I think I might go one step further in remaining security neutral. We also need to more strongly "advertise" the need for people to now validate signatures against a key sourced from an ASF machine to encourage people to take that extra step. Easily done however. (Part of the download page etc.)
i am a release manager over in jakarta-land. i'd strongly advocate repeating the 'you must validate the signatures' message as much as possible. i personally try to include it on every news item and announcement i create for a release.
over in jakarta-land the message is also repeated in the download page (eg http://jakarta.apache.org/site/binindex.cgi) and often in the download directory README.html (eg. http://apache.ttlhost.com/jakarta/commons/beanutils/). i'd say that these are good practices and worthy of imitation.
- robert
--------------------------------------------------------------------- In case of troubles, e-mail: [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]