On Mon, 2014-06-16 at 20:14 +0200, Jakub Wilk wrote: > debian-keyring is not useful for automatic authentication of source > packages. Well to be honest I never fully understood the idea behind debian-keyring... IMHO this should be actually debian-developers-keyring and it should be intended just for offline systems (and thus have only little use in the real world).
The actual system of telling whether someone is a Debian Developer should be via signatures from a special key on the respective Debian Developer's public key. That special key lets call it "Debian Developers Authority" is controlled by the people who give DD status to others and who (right now) add their keys to debian-keyring. Signatures on DD keys could be either generally expiring after one year... on could make a simple process that automatically signs the key for another year if the respective DD requests for renewal. If not,... you easily sort out MIA people,... such people could in the worst case have died and their private key might now be in the possession of some other guys... or just laying around on some harddisk thrown away... So such a process of automatically sorting out DDs if they don't renew could have some benefits from a security POV... if a DD forgets to renew in due time... one could think about a easy (but more verifying) process to give him back his new signature. And even if one doesn't like that process of always expiring signatures, one could simply give non-expiring signatures... and the people who now remove keys from debian-keyring and mark DDs as being retired or emeritus... could revoke the signature made with the "Debian Developers Authority" key. For any relevant system (e.g. of the build system or whatever else) a signature would be trusted, if it was signed by a key which in turn was signed by that "Debian Developers Authority" key. One could even extend this, to denote special rights of some people by other such keys,... e.g. "Debian Security Team Authority" or "Debian Project Leader Authority", etc.. The existing debian-keyring package could be retained for offline systems and simply be regularly filled/updated with keys that are signed by the authority. As a nice side effect one could use the existing keyserver network just as it is... no need for a special key database like debian-keyring. I mean most services like the build services probably never see _all_ of the different DDs regularly, right? So if an upload was made with some key ID 12345678, that key could be fetched on-demand, and one would simply set up gnupg to only trust such keys, that are signed by one of the authority keys. Well perhaps I oversee some problems (this is just a short sketch of how things could be done... completely ignoring advanced features like trust signatures, that may be very fancy in such a trust hierarchy)... but I don't know all the details and it's already past 04:00 am ;) > The source package could have been signed years ago by a > person who is no longer a DD. Or signed with a key that has been just > replaced with another one. Or signed with a key that's not yet shipped > in the package. Well I think most of the timing problems could be solved with a system as proposed above... And somehow it must already now be assured that a key is marked as "this is a DD"... so you don't win/loose anything here, when such a system as described above would be used. With respect to "the source package could have been signed years ago"... well sure... the whole idea of DD signatures on packages doesn't take away the need for signed repo files, which contain valid from/through dates and the list of currently valid packages. The idea is just, that having both, might help in case one fails (e.g. due to some bug as we've had now). > [0] And his skepticism was reinforced by (independent) discovery of this > bug: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1098738 *sigh*.... and this is still open? 8-O I mean MD5 is _really_ broken now... actually I think any secure APT system should always verify _all_ of the present sums and fail if _any_ of them doesn't match.... and it should _always_ expect at least one hash some type to be present (i.e. a secure one like SHA3, or SHA512) Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
