On Mon, Apr 03, 2000 at 01:01:30PM +1000, Anthony Towns wrote: > On Sun, Apr 02, 2000 at 02:57:06PM +0200, Marcus Brinkmann wrote: > > > > As dinstall verifies the keys on the packages (which already exist, btw, > > > > they are just not propagated), it puts itself in the middle of the > > > > chain: > > > Well, as Jason points out, they are propogated: by the -devel-changes > > > list. > > They are not delivered to the user when he is downloading a deb, with no > > dselect method, and not with apt, and espcially not when downloading the > > package manually. > > But they could be, with minimal changes. Stick the latest .changes files > in debian/changes somewhere and add some code to apt to get it.
The changes file would be sufficient, but it is not ideal, because it always signs a group of packages. Much better would be to stick the signature inside the deb. > I'd be interested in seeing some code for this. You keep throwing around the > word `easy', as though it *is* just as plausible to implement this method. > Please, at least write some pseudocode for it. before making the ar, run pgp/gpg on a list of md5sums of all files contained in the ar. Add this signature to the ar. When extracting a deb, verify the md5sums and the signature. > Make sure you consider the necessity of keeping debian-keyring up-to-date > in case of compromised keys. Make sure you either explicitly do use a > `single key' that's easy to verify, or not. If you do, make sure you allow > some way of coping with James' key being updated, or James retiring and > someone else taking over the job; and make sure you cope with upgrades > that possibly skip the generation where this happens. Of course. This all is not different from the dinstall keyring, and should be solved in exactly the same ways. [snip] > Marcus: How would dpkg with debian-keyring handle all this? > Well, the default should be to use the installed debian-keyring. This will work well for Debian native packages. Of course, care has to be taken when updating it (and this should be done manually, IMHO). For third party packages, we can allow a seperate key-ring, where root can add public keys from third parties he trusts. There could be a default /etc/debian/third-parties-keyring.pgp or it could be specified at the command line. The origin of the package should be displayed at installation time, of course, if verificable. > And note that saying `This distribution is Debian' is different to > saying `This distribution is made up of stuff put together by Debian > maintainers.' The latter could be put together for a special series of > `When Packages Attack!' and include all the best security holes ever > distributed by Debian. So dinstall (ha!) or lets say the admin team is doing a security check on all packages before adding them to the archive and to the Packages file? They are auditing the source and recompiling the binary packages before making a release? What Debian ships IS "the distribution is made up of stuff put together by Debian maintainers." And this, I think, is the critical point. The signed debs case integrates well with a distributed system like Debian is, where there is no central authority to decide what's good and bad. And this is the way Debian should be. If you are claiming that what Debian ships is something different than what the maintainer put together, I shall neglect all responsibility for all my packages from now on. I read the rest of your mail, but I don't think there is much else I would answer differently than I did before, and it is preferable to keep the reply short, to focus on the new things. Thanks, Marcus
