On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote: > Russ Allbery <r...@debian.org> writes: > > > Simon McVittie <s...@debian.org> writes: > > > >> Most packages (in terms of proportion of the archive, in particular for > >> architectures other than i386 and amd64) are built by a buildd, so each > >> buildd would have to have a signing key that could sign the checksums > >> file during build. Further, the build part of a buildd runs inside a > >> limited chroot running the target distribution, i.e. usually unstable > >> (the "real system" runs stable with a backported version of sbuild), > >> which doesn't have access to any key material in the "real system". > > > >> At the moment buildds don't have their own keys: a buildd maintainer > >> inspects the build log and signs the .changes file for upload. > > > >> Even for maintainer uploads, maintainers who build their packages in a > >> minimal chroot with schroot, pbuilder, cowbuilder etc. (which is > >> strongly recommended) don't necessarily have their signing key available > >> inside the chroot (nor should they!). > > > > Signatures per buildd or per DD doing uploads are moderately interesting, > > but not nearly as interesting as a signature by a long-term stable key > > such as the archive key. > > > > Do we actually rely anywhere on packages not changing hashes between > > upload and publication in the repository, or is it just something we have > > as an invariant now because there's no reason for it not to be one? The > > path of least resistance here would be for DAK to add the package > > signature after verifying the signature of the uploader. This has the > > drawback that it modifies the *.deb and therefore breaks the hashes in the > > *.changes file and hence its original signature, but given that we throw > > out the *.changes file anyway, do we actually care? > > The changes files are afaik archived somewhere and are needed to verify > the archive integrity after a (feared) compromise. > > And what do you do when the archive key expires? Resign every deb in the > archive and have every mirror download them all again?
Why? A signature doesn't become invalid just because the key expires, as long as the signature was created before the expiration of the key. > Same problem on > releases. Releasing a new stable means a new stable key so every deb > needs to be signed again and changes. I don't think this is a good idea. > This would also cause users (apt/aptitude actually) to reinstall the > packages needlessly creating even more mirror load. > > For this to work the signature for the checksum files should be detached > so that it can be changed/extended without altering the deb files. > > I suggested this before but lets repeat it. Why not include a digest of > the checksum file in DEBIAN/control, carry it into the changes file and > into Packages.gz. That way all current debs automatically have a clear > trust path. > > Further the changes files could be included in the pool alongside the > debs and source files. That way everyone can verify the autenticity of > the debs (or just the checksum file) independent of the archive > key. Going one step further the changes files could be signed by the > archive key(s) as well. Adding a new signature to them when keys change > does mean they need to be mirrored again but they are relatively small. Self-contained packages, where the signature is included and installed along with the checksum file, would have a lot of advantages. You wouldn't need access to a lot of infrastructure just to verify a signature. It would be very simple. It could be used for packages, that are not part of Debian. For instance, I could produce a package and send it to a friend and he could later use my key for verification. The same holds for projects that publish deb files. With your proposal they would need a full fledged archive and keep a long history of all the files. And what do you do with packages from testing/unstable/experimental? Would you keep all incarnations of the Release/Packages/changes files? And if I want to verify the signature of an installed file, from a package I once installed from, say, unstable, how would I find the right version of the changes file for the package? Cheers, harry -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100318113959.gc17...@nn.nn
