[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: improving downloader packages (was: Re: holes in secure apt)

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
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)


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: