On Mon, Apr 03, 2000 at 12:02:29PM +0200, Marcus Brinkmann wrote:
> > 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.
Agreed. But if we want to get anywhere, this seems like an easy way to
start prototyping.
I know I'm coming across a bit as `your way sucks, and you're lame and
stuff' but I don't actually mean it. If we can move this discussion to
actually getting some code done, I'm more than happy.
> > 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.
Verify the signature against what, exactly? .../debian-keyring.{pgp,gpg} ?
What about packages made up by Storm, or Corel, or third parties?
Should any .deb be allowed to happily overwrite the keyring file? [0]
How do you check that the keyring is only updated by James?
I'd particularly like you to make a decision on using James' key or
not. Either way has problems, which we're not going to ever solve if you
just keep changing your mind on whether you have a source-of-all-trust
or not, depending on which works better in a given paragraph.
> > 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.
The key itself can be updated (without verifying it) during an apt-get
update. This key can be signed by *all* past dinstall keys. Similarly
for the security key. You check that it's either the same as your
current keys, or that its signed by your current keys, and use it if
so. Reasonably easy.
This doesn't work so well if your source-of-all-trust is James' key:
signatures by his key probably just certify that he's seen your passport,
not that you should be trusted by every Debian user ever. If James quits
the project, he's not going to give us his personal key so we can use it
to sign each of the subsequent dinstall maintainers keys, and he might
not want to be bothered doing this himself, either.
Oh, another problem. What to do about a maintainer's existing packages
when he retires? Presumably his key is pulled from the keyring, but then
how does someone go about installing one of his packages? Do -qa have to
pointlessly go through and recompile all his packages? If they're going
to be putting their name to them, are they going to be comfortable with
just blithely signing packages they don't have time to carefully audit?
> > 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).
If it has to be done manually, most people will forget to do it. If
they're keyrings aren't uptodate, much of their security goes out
the window.
> > 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?
No, obviously. But as things turn out, at any one time, Debian doesn't
have all that many (known) security bugs. If you don't have to choose any
/one/ time though, and can select the worst instance of netbase, and the
worst instance of make, and the worst instance of mh, and so on, you can
come up with security holes or grave bugs in a lot of packages. (There
are 166 packages with urgency=high uploads on my system, for example)
> What Debian ships IS "the distribution is made up of stuff put together
> by Debian maintainers."
Yes. But not every collection of stuff put together by Debian maintainers is
something Debian ships.
Mixing up things from experimental and bo and woody would be `made up
of stuff put together by Debian maintainers', but it'd probably be as
buggy and unusable as all get-out, and yet people could burn CDs of
it which you could then verify as being as official as anything else
Debian distributes.
Considering how much effort we put into keeping the distribution
consistent, and getting rid of horrible bugs from stable, that sort of
outcome would really be a little disappointing, to me.
The individuals are the basis and all, but the group's important
too. Think emergent properties, and so on, maybe. (Hi, Jason!)
> 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.
No central authority but James, you mean?
Alternatively, the dinstall key is good, because it doesn't give power to
a person; it gives power to the entire project, who can as a whole decide
how that power will be used.
And if someone, like Corel, or Storm, or whoever wants to take bits from
Debian and add bits themselves, all they have to do is generate a Packages
file, sign it, and make the public key available. This isn't limiting
anyone to What-Debian-says-goes, at all. At least as far as I can see.
> 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 realise this is a pretty popular rhetorical technique these days,
but really...
Cheers,
aj
[0] If you really wanted to avoid this *without* changing dpkg (you only
need to change Apt to verify signed Packages files) you could have
Apt memorize the various keyrings and such, and write them back
before quitting. postinst's which fork() and sleep for an hour or
so, could probably get around this though. Hmmm. There's probably
no real way of doing this, actually.
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG encrypted mail preferred.
``The thing is: trying to be too generic is EVIL. It's stupid, it
results in slower code, and it results in more bugs.''
-- Linus Torvalds
Attachment:
pgpPy8IdBuSoS.pgp
Description: PGP signature