On Fri, Mar 19, 2010 at 09:14:13AM +0100, Frank Lin PIAT wrote: > On Thu, 2010-03-18 at 12:39 +0100, Harald Braumann wrote: > > On Thu, Mar 18, 2010 at 08:31:40AM +0100, Goswin von Brederlow wrote: > > > Russ Allbery <rra@debian.org> writes: > > > > Simon McVittie <smcv@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. > > > > 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. > > Oh please no. Don't advocate sending individual .deb files, ever. That already happens, will always happen, and it cannot be avoided. There are perfectly valid use cases for using "individual .deb files". To give but one example that comes directly from my day job: I build an image for an embedded system that boots off a read-only /. Since we can't modify our filesystem after booting, the way an update is done is through "regenerate the image and boot off a USB stick", rather than "apt-get update". Since the latter doesn't work anyway, setting up a full repository with Packages file and whatnot is vast overkill, so the software that was written specifically for this system is packaged as a .deb file that is not in a repository, anywhere. > This practice should be strongly discouraged. One brilliant part of > Debian packaging *is* the APT infrastructure, some key features: In the above example: > 1. Security updates Does not apply (when the devices are connected to a network, that means they're either undergoing maintenance or someone is trying to break into the system) > 2. Bug fixes "If it ain't broken, don't fix it" applies even more to this kind of embedded systems than it does to servers. > 4. Dependency resolution "apt-get -f install" > 5. Smoother dist-upgrades because: > 5a. The APT repository provides newer version, with updated > dependencies (libraries transitions...) the custom software does not include libraries > 5b. The user don't have to visit each web site to dist-upgrade hah. > 6. Single GPG key to manage (revocation ; update...) I don't understand what you mean by that. > 7. Single GPG key to trust (per repository) Well, signatures on .deb files would also have a "single" GPG key to manage, per source. There's no difference here, really. It's important to remember that whatever environment you're using Debian in, is not necessarily the *only* environment Debian is used in. Since a method that will work for individual .debs will also work for archive-wide installations, there really is no problem in doing it in such a way that it will work for both ways. I agree that for most cases, setting up a proper repository is the best way to distribute software. But there are exceptions, and even in those cases having a path from the binaries on disk to a GPG signature is a good thing. [...] -- The biometric identification system at the gates of the CIA headquarters works because there's a guard with a large gun making sure no one is trying to fool the system. http://www.schneier.com/blog/archives/2009/01/biometrics.html
Attachment:
signature.asc
Description: Digital signature