Re: Revival of the signed debs discussion

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Andreas Barth <aba@not.so.argh.org> writes:

> * Goswin von Brederlow (brederlo@informatik.uni-tuebingen.de) [031201 14:40]:
> > Instead of keeping extra files with the signature of the deb the
> > information could be stored inside the deb itself. Of cause the
> > signature can't be contained in the thing being signed. Instead the
> > signature would be added to the end or the ar archive and contain
> > signatures for all the files (uncompressed?) before it in the archive.
> > [...]
> 
> In principle I agree with your plan. Just a few suggestions what could
> (perhaps?) be also done:
> 
> I would like it even more if there would be something along each
> package that identifies what was done to the deb-file since creation
> (see it as a something like a "passport" or "signature file", where
> each entry adds new information to the file).
> 
> This would also have the advantage that a system administator could
> verify signatures without following who is accepted as a DD, and who
> is resigning - without a compromise of the debian server, verifying
> any deb with the archive key is enough. If there is however a
> suspecion of problems, he could always make stricter checks, without
> requiring more infos from the archive. (And of course, any
> administrator could also make checks stricter and demand a signature
> by a DD plus a signature by the archive script).

The Packages/Sources files with Release file already give that trust
chain. But given thats debsigs only adds 132 bytes to the deb having
signatures by the buildd, the uploader and dinstall looks feasable
space wise. You wouldn't gain any extra security from the dinstall
signature but it would mean one only has to check one method.

> More in detail this would mean that after building, the maintainer
> signs the md5sums, and a "build this package on <date>".
> 
> After accepted by the archive, the archive script adds a line with
> something like "accepted by katie on <date> because of good signature
> of <Name> <KeyId>" to the top, and signs the whole thing.
> 
> This has one major drawback: Either the deb-file must be changed
> during acceptance to the archive, or the "passport" must reside in an
> extra file. (And there is of course a "mixed mode" possible: Extra
> file at the moment, and after sarge is released, the files move within
> the deb.)

The changes can be added as _foobar files to the deb savely just like
debsigs does.

> Technical details should IMHO be discussed later, but a sample
> passport could look like:
> 
> accepted by katie on Mon,  1 Dec 2003 20:34:58 +0000 because of good signature of DD, KeyID 0x01234567
> build by DD on Sun, 30 Nov 2003 14:34:33 +0100
> mgetty-voice_1.1.30-6_i386.deb
> 450b2b4ffa0be49b43f7358099117f7d control.tar.gz
> fb00a05d140ec3e830d6227f3fdd743d data.tar.gz

All debs would contain the same string "accepted by katie on * because
of good signature of DD, KeyID *". Thats a lot of bytes wasted.
The date is already stored in the ar archive so thats wasted too.

Each signing instance should have an unique key. They key ID then
identifies who signed it and the reason (being allways the same) could
be documented in some Readme.

I agree with you that every instance along the way to the archive
should sign the package:

1. maintainer
2. sponsor
3. buildd
4. buildd admin
5. dinstall

debsigs allows for 10 chars for the name of the signature.
8 chars would be key ID.
1-2 chars could be used to denote the reason of the signature:

DM - DD maintainer
NM - non DD maintainer
DN - non maintainer upload by a DD
NN - non maintainer non dd upload
SP - sponsor
BD - buildd
BA - buildd admin
DI - deinstall

Or just letters from A-H.

MfG
        Goswin