Re: Signing Packages.gz
I partly concur. Even if the developer-user channel was completely secured by signatures et al, we would still have the problem of an attacker gaining very much by breaking into a single developer's machine. You're netbase package is a good example: it contains a couple of programs usually started as root. If your developing machine is compromised, and your copy of the source modified, the evil guy may gain entry into a large number of Debian boxen. All packages can run things as root. Even the most simple game.
Re: Signing Packages.gz
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.
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.
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.
I'm sorry, but that's a matter of opinion. If you're really *hugely* worried
about the security of master, then please, show us your scripts that you've
already had to write to cope with the fact that master's so insecure it's
probably already compromised.
If you compare the security of PGP with the security of any linux machine,
you will easily see the difference.
Right. Now compare the security of one particular linux machine, namely
master, with the security of the weakest machine used by a developer. You
ought to be able to see the difference there, too.
Yes, it's a problem, but one you seem to be vastly overrating.
Are we talking about security, or are we talking about belief?
If we're talking about trust, which we are, then we're immediately talking
about belief. Belief is quite fundamental to security analysis, it's the
fundamental unit in BAN logic, eg.
I am very irritated that people who want to propose and implement a security
measure for Debian packages are building on likeliness and probablility, and
on the fact that master is quite secure.
We've got a choice: do we trust master, or do we trust that mirrors won't be
compromised by developers? How do we choose? Liklihood, probability, how
easy the weakest choices can be compromised.
What about all the packages on other systems? Third party packages? Packages
I build locally? There is a solution which covers individual debs even,
where I don't know any more where they come from.
Packages you build locally? Huh? If someone's already compromised your local
machine, what security is adding signatures going to give you?
For third party packages, you have a point. Most third party packages are
distributed in an apt-able way these days, though, in which case most of
them have a Packages file that can be signed. If you want Apt to verify
and trust the signature, you'll probably have to move the appropriate public
key into an apt configuration file somewhere first, though.
Jason: I'm thinking, probably, something like:
Gpg::KeyRing {/etc/apt/apt-keys.gpg;}
Gpg::Origin
{
Name {Debian;};
KeyID {0x12345678;};
}
Gpg::Origin
{
Name {IPv6-staging;};
KeyID {0xabcd9876;};
}
where the Gpg::Origin::Name's match the Origin field in the Release files.
I'm not quite comforable with the `KeyID' stuff. It's very easy to make a
key with the same KeyID as another, so as identifying information, that's
pretty weak. OTOH, to actually get it installed, you'd have to overwrite
the Apt keyring, so anyone whose going to compromise your system has to
have already compromised it, which isn't too bad, I guess. I wonder, though
if it mightn't be better to also specify a fingerprint, which apt can
check for itself.
This is also somewhat difficult to verify if you want to allow updates.
You could probably do it if you had a different .gpg directory (with
separate gpg keyrings and separate trustdbs) for each Origin. That'd
be pretty ugly though. Possibly a `--check-trusted-by keyid keyid'
option needs to be added to gpg, so you can check that whatever key was
used to sign a Packages.gz file from Debian is at least certified by the
key you verified by hand yourself. Alternatively, you could just say
Aieee! The Debian/unstable key has changed again! Please verify this
by hand and update your apt.conf! which could get tiresome.
Marcus: How would dpkg with debian-keyring handle all this?
signed packages -- dinstall
\ 1
\-- user
1
Really, what we have is:
maintainers -3-.
| V
1
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 01:00:56PM +0200, Bart Schuller wrote: On Sun, Apr 02, 2000 at 02:46:30PM +1000, Anthony Towns wrote: PGP (v2.x, I'm not uptodate with the recent OpenPGP stuff), generates a secret (albeit symmetric, rather than public/private keypair) IDEA key everytime you try to encrpt a message. It encrypts the message with this key, then encrypts the key with the recipients public key, and (and here's the bit I was referring to) *sends that secret IDEA key across the net*. But you might emphasize that this secret key is used exactly once, just for this message. Intercepting it won't allow you to sign other stuff as someone else. Intercepting the IDEA key will let you do one class of bad things (reading a supposedly confidential message), intercepting the security-key will let you do another class of bad things (impersonating the security team). Intercepting one key isn't particularly easier or harder than intercepting the other. The point is that in both cases intercepting the key is a Bad Thing. The point is that in both cases, any possibility of intercepting the key has to be avoided for any security to exist at all. And the point is that in both cases on-the-wire interception of the key is avoidable by the simple expediency of encrypting the key before sending it. Why do people seem to think signing stuff is some black art, and wave chickens legs about and act all superstitiously when talking about sending things over the net, or putting things on a semi-public computer? There's nothing to be superstitious about. There are valid risks to consider and then avoid, but that's *it*. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpzIKxqiVyHr.pgp Description: PGP signature
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 07:44:56PM +0200, Robert Bihlmeyer wrote: Note that *any* keys that your agent holds can be snarfed by the admin(s) of any hosts where you ssh-in with agent forwarding enabled. As I understand it, you can't actually *obtain* the keys, you can just *use* them. Often though, this is just as good. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpGxvKFGrPN7.pgp Description: PGP signature
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 06:52:37PM +0200, Robert Bihlmeyer wrote: It's currently the case, yes, but it *could* be changed. You could, for example setup dinstall so that it wouldn't accept NMUs of certain important packages (such as gnupg). A good idea. Still: with package-granularity, this decision is made by the users, not the Debian administrators. Users don't have enough information to make such a decision, however. How do they know if James allowed a particular NMU to be made, because not only did he not have time to make the upload himself, but because there was a huge nefarious vulnerability there that made gpg accidently distribute the user's private key along with every signed message? Debian *can* make this decision, because we know each other. Most users can only go `James who?'. And, equally, a deliberately compromised package would probably get a fair bit of coverage too. It'd be nice not have to rely on staying up to date with slashdot and the mailing lists and IRC before doing an apt-get dist-upgrade though. If you trust the debian-keyring maintainer, there is no problem for you: your keyring will get updated (to a version w/o the bad guy's key) and then any other packages get upgraded. People will probably also quickly updated packages compromised by this guy with fixed versions. And if he's already compromised your local mirror, and decides that no one needs an updated debian-keyring, or any of those irritating bugfree packages? To reiterate: signed .debs don't cope with any of the following attacks: * Past/current developers doing nefarious things, especially if they also manage to compromise your local link in the distribution network. * Vandalism against Packages files * Maliciously distributing the worst possible selection of valid packages These attacks are all based on the fact that sometimes it's Debian as a whole acting in concert that you trust, not any and all particular developers. Signed Packages.gz don't cope with master being compromised, or similar. That is, if you trust Debian as a whole, that's a single point of vulnerability. Note that signed .debs also don't cope easily with Debian being compromised for new users, who don't have an existing copy of James key or the entire keyring to check against. Sometimes it *is* Debian that you trust, not arbitrary maintainers. If there is consensus that the maintainer put a backdoor in on purpose, he will get kicked, a new version of debian-keyring will be produced, and the situation is repaired. And if he's doing this on purpose, he'll likely go and compromise some other systems, like, say, some downstream mirrors. And if a developer gets kicked out? You can't revoke a signature (PGP signatures are designed to certify identity, not trustworthyness), GPG can revoke signatures, so your conclusions do not apply. Huh, so it can. Having x signatures on every maintainer key, where x-1 of them have been revoked still seems thoroughly inelegant, however. And again you have the usual problems if someone compromises one of the machines with this `super key' on it. Indeed. But this machine could be made more secure than the debian main machines could ever get (there's no need for people other than the signer being root, etc.) Hmmm? The `signer' in this case is `Debian'. There should really be no need for non-Debian people to have root on master. To some extent sponsors are Debian people, too. Again, all these complicated distributed methods are great and all, but they *aren't* actually particularly more secure, and nor are they more convenient. I don't think it would more complicated for developers. Perhaps one additional entering of their passphrase, while building the .changes file, but that's it. Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload. (each .deb has to be signed separately, no matter which way you do it) Users could choose their paranoia level. From trusting (same as now) to paranoid (only trust packages signed by a key which is signed by my own key). This is very cliquey. Not everyone knows everyone else, even within Debian, let alone thinking about people who've never met a Debian developer in their lives. So afaics, users can really only choose exactly one paranoia level: allow everything in every package to be uploaded by anyone. I'm yet to see a reasonable method of restricting even uploads of debian-keyring that also allows James to resign. In some vague academic sense, they're harder to compromise *completely*, but I don't think that makes any particular exploits any harder to perform, practically speaking. I partly concur. Even if the developer-user channel was completely secured by signatures et al, we would still have the problem of an attacker gaining very much by breaking into a single developer's machine. You're netbase package is a good example: it
Re: Signing Packages.gz
Nicolás Lichtmaier [EMAIL PROTECTED] writes: All packages can run things as root. Even the most simple game. Doing clandestine things in a install-script is harder than in a binary. -- Robbe
Re: Signing Packages.gz
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
Re: Signing Packages.gz
On Mon, Apr 03, 2000 at 10:24:02AM +0200, Robert Bihlmeyer wrote: Nicolás Lichtmaier [EMAIL PROTECTED] writes: All packages can run things as root. Even the most simple game. Doing clandestine things in a install-script is harder than in a binary. #!/bin/sh /usr/games/mygame --update-score-file-format ...with the malicious code in the game source itself seems pretty clandestine. Self-modifying postinsts are probably possible too, with some care. Cheers, aj, thinking like a criminal since 1978 -- Anthony Towns [EMAIL PROTECTED] 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 pgpnCfAos9jDc.pgp Description: PGP signature
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 08:11:15PM +0200, Torsten Landschoff wrote: We might want to revoke the old key. If James leaves we can't revoke his key because it is HIS key. We can however revoke the dinstall key because it is by definition Debian's key. But this is nitpicking. Who is Debian? Where is the safe where the secret key will be stored (as the keys from Microsoft are)? Who will be responsible for all this, and what makes you belief that those will be more careful about the key than James? The central authority doesn't mix extremely well with the distributed organization Debian is. Note that a signed Packages file works extremely well for a single cooperation who produces a Debian based distribution, or an individual. People keep forgetting about Debians nature, and this keeps bothering me. You have started the child game. We want to make a simple change to apt as dinstall and you keep telling us that it won't make things better. Now you said that making things better but not perfect is not the Debian way of doing things. Yes. Because the Debian installation tool is dpkg, and not apt. This is the second main point that I disagree with (aside of the security discussion, which is complicated and by now covered well). A solution for Debian should serve all people, those who use apt, those who use dpkg and downloaded files, those who use other methods (dselect etc). Thanks, Marcus
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 02:30:12PM -0600, Jason Gunthorpe wrote: On Sun, 2 Apr 2000, Marcus Brinkmann wrote: This is a seperate problem. I agree that this should not be the case, but it has no place in this discussion. If individual developer keys are compromised, we have a problem no matter what. Developers should not store secret keys on net connected machines, point. However, this only affects the developers packages, not the whole archive. ^ GAH!? Don't you see that isn't true?? Look, a hack attempt would go like this. 1) Break root on master 2) Use that to break user account on developer victum (any will do) (Hint: I have already shown that torsten at least could be attacked quite easially) 3) Steal PGP key 4) Use stolen PGP to form new glibc package with trojan, sneak into archive using #1 And it wouldn't be strange that random Joe is uploading a pgp package? And random joe or the real glibc maintainer will not speak up if this really happens? But you have a point, and I add this case: This only affects the developers packages and NMUs. (one could vaguely interpret a NMU as the developers package, as it is carrying his signature, but I admit that I didn't have NMUs in mind when writing this.) Thanks, Marcus
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes: On Sun, Apr 02, 2000 at 07:44:56PM +0200, Robert Bihlmeyer wrote: Note that *any* keys that your agent holds can be snarfed by the admin(s) of any hosts where you ssh-in with agent forwarding enabled. As I understand it, you can't actually *obtain* the keys, you can just *use* them. Often though, this is just as good. Yes. Snarf was the wrong word. Just being able to use them while the user is connected restricts your time to find the hosts this key unlocks. -- Robbe
Re: Signing Packages.gz
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
Re: Signing Packages.gz
On Mon, Apr 03, 2000 at 12:10:27PM +0200, Marcus Brinkmann wrote: We might want to revoke the old key. If James leaves we can't revoke his key because it is HIS key. We can however revoke the dinstall key because it is by definition Debian's key. But this is nitpicking. Who is Debian? Look around you. Look in a mirror even. You know the answer to this. Where is the safe where the secret key will be stored (as the keys from Microsoft are)? Who will be responsible for all this, and what makes you belief that those will be more careful about the key than James? master.debian.org; debian-admin and the ftp people; and mu. We've been over this. The central authority doesn't mix extremely well with the distributed organization Debian is. This isn't a central authority, and it does actually mix well with Debian. It doesn't create a choke point, it's easy to implement, it doesn't add any authority to anyone, or extra control to anyone. This argument, coming from you, actually makes a hell of a lot more sense to me than some of the others made in this thread. But I don't *think* it's actually a problem: it formalises the group yes, which can definitely be dangerous, but it doesn't centralise it, or distort it, or restrict it, or anything, as far as I can see. (This is in contrast to the constitution, eg, which does centralise some things, and does distort others. General resolutions are a distortion of the regular cut-and-thrust of consensus building, eg) You have started the child game. We want to make a simple change to apt as dinstall and you keep telling us that it won't make things better. Now you said that making things better but not perfect is not the Debian way of doing things. Yes. Because the Debian installation tool is dpkg, and not apt. dinstall is a part of dpkg, and Apt is now the main dinstall method. That makes apt pretty central to Debian. That's the first point. The second point is that signed Packages are incredibly easy to verify manually. You run ``gunzip Packages.gz; gpg --verify Packages.gpg Packages'' ie, people who don't want to use apt can quite happily make use of these signatures, in their favourite dselect method. If you want to verify a particular package, you can (hypothetically) do: gunzip Packages.gz gpg --verify Packages.gpg Packages # check to see that it's signed by the right key, as well as # that it's a valid signature MD5a=`grep-dctrl -F 'Package' -s MD5sum '^telnetd' Packages | cut -d\ -f2` MD5b=`md5sum telnetd.deb | cut -d\ -f1` if [ $MD5a = $MD5b ]; then echo MD5sum match else echo MD5sum mismatch :( fi As far as ease-of-use and good-use-of-bandwidth-and-time go, I think signing Packages.gz is optimising for the right case (ie the common one). This is the second main point that I disagree with (aside of the security discussion, which is complicated and by now covered well). A solution for Debian should serve all people, those who use apt, those who use dpkg and downloaded files, those who use other methods (dselect etc). Is this satisfied too, now, then? Well, perhaps not satisfied, but at least somewhat alleviated? (For people who download by hand and just use dpkg, clearly dpkg --check-deb-sig is obviously much more convenient) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgptI2OzyzXt1.pgp Description: PGP signature
Re: Signing Packages.gz
On Mon, Apr 03, 2000 at 12:49:24PM +0200, Robert Bihlmeyer wrote: As I understand it, you can't actually *obtain* the keys, you can just *use* them. Often though, this is just as good. Yes. Snarf was the wrong word. Just being able to use them while the user is connected restricts your time to find the hosts this key unlocks. And it might be worth mentioning that `ssh -v' from your local host, will let you see which machines are getting your ssh-agent to do stuff. This can get a bit ugly, but it's probably worthwhile. An exercise for someone interested: hack ssh-agent so it pops up a window which you can use to say `yes' or `no' to requests from non-localhosts for secret key operations. Usual provisos about making this an option, and not breaking things for people who don't use X, and so on. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpJLxPY5x8WP.pgp Description: PGP signature
Re: Signing Packages.gz
On Mon, Apr 03, 2000 at 01:36:01PM +1000, Anthony Towns wrote: Debian *can* make this decision, because we know each other. Most users can only go `James who?'. This is easily identified as a play with names. Who is this Debian person you refer to anyway? After all, behind every action is a developer. And if he's already compromised your local mirror, and decides that no one needs an updated debian-keyring, or any of those irritating bugfree packages? This is free software after all. You can already make a mirror that only carries out of date packages. What sort of an attack is that supposed to be? To reiterate: signed .debs don't cope with any of the following attacks: * Past/current developers doing nefarious things, especially if they also manage to compromise your local link in the distribution network. I still disagree (the details are spread over several mails of course). * Vandalism against Packages files Can you explain this attack to us? * Maliciously distributing the worst possible selection of valid packages See above. Seems to be a Free Software attack to me. Maybe you should file a bug report against the GPL. (You didn't laugh? Sorry, but it was supposed to be funny :) These attacks are all based on the fact that sometimes it's Debian as a whole acting in concert that you trust, not any and all particular developers. A Debian as a whole does not exist. There exists an abstract incorporation, but that's it. The rest is a bunch of developers. I don't see the difference in trusting the key of James or some other Debian admin. I see a difference between a personal key and a key which is lying around on some net-connected machine. You are attempting to abuse the public key (PGP) protocol to verify a group as the ownership of something. This can't work, because it was not designed to cope with such a situation. You would need to use an entirely different cryptoprotocol to solve this. All problems I see (and you keep to sweep under the table) are a direct result from this. Instead, with signed debs, the PGP protocol is used exactly for what it was designed: A signature from an individual, not from a group. (Of course, you *can* have a key that is accessable to several people, for example for organizations, as Microsoft. However, those people have to share the location, and thus act like one abstract individual. That the same can't be true for Debian is obvious: We don't have a headquarter). One note: Of course this is not the case if the Packages file is signed locally by an indivual. But in this case, the analogy to the debian-keyring key is complete (only the technical details are different, and individual debs can't be checkd of course. ) Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload. (each .deb has to be signed separately, no matter which way you do it) There are solutions to this. (Read the pgp/gpg manuals). You can pass the phrase from other programs or the environment. As a side note, realize that the secret dinstall key can't be protected efficiently by a passphrase, because the phrase itself had to be stored and readable by dinstall. Securing the way Debian distributes its software is a *long* way from making it impossible for an attacker to compromise huge numbers of Debian boxen. And is of course an orthogonal issue. Thanks, Marcus PS: I would like to meet this Debian person, he must be terrible shizophrene. ;)
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes: Users don't have enough information to make such a decision, however. How do they know if James allowed a particular NMU to be made, [...] It would probably be better to let this essential package be maintained by a small team. Three or four people would suffice to lower the probability of all of them being busy at the same time. An upload of any of these would be valid for Debian as a whole (but individual users could still choose to mistrust some of them). Debian *can* make this decision, because we know each other. Most users can only go `James who?'. Those users will have to trust Debian, in the incarnation of the Debian website, or official CDs. Both of these would list the keys of the keyring team at least. And if he's already compromised your local mirror, and decides that no one needs an updated debian-keyring, or any of those irritating bugfree packages? This is a problem, that is not solved by a signed Packages.gz. If some package has an exploit (through malice or because of the usual oversight), somebody controlling a mirror can always prevent updates from filtering down. People usually read security-news-services to get around this. To reiterate: signed .debs don't cope with any of the following attacks: * Past/current developers doing nefarious things, especially if they also manage to compromise your local link in the distribution network. Not true for past developers. With regard to current developers, it's the same with signed Packages.gz. * Vandalism against Packages files My solution was to sign the metadata (possibly, *only* the metadata, since it includes an md5 of the package proper, anyway). * Maliciously distributing the worst possible selection of valid packages I think that packages having security bugs should be fixed/removed with haste. Then this degenerates to the preventing updates problem. GPG can revoke signatures, so your conclusions do not apply. Huh, so it can. Having x signatures on every maintainer key, where x-1 of them have been revoked still seems thoroughly inelegant, however. I don't see why you think this is necessary. This does *not* involve changes to the master-key or any other maintainer's key. The new keyring just includes a new version of the kicked maintainer's key with one additional revocation-signature. This new signature tells that this key is no longer trusted. Example: $ gpg --check-sigs testkey pub 1024D/36FF3F58 1999-07-24 Robert Bihlmeyer (Testkey - do not use) rev! E6583EFB 2000-03-31 Robert Bihlmeyer [EMAIL PROTECTED] sig! 36FF3F58 1999-07-24 Robert Bihlmeyer (Testkey - do not use) sig! E6583EFB 2000-03-31 Robert Bihlmeyer [EMAIL PROTECTED] This key is self-signed, signed by E6583EFB, and there's a revocation by E6583EFB on it, invalidating all signatures by E6583EFB. Yes, you can distribute a keyring package that is stripped of this revocation-signature, but you can't distribute a signed package of it. Indeed. But this machine could be made more secure than the debian main machines could ever get (there's no need for people other than the signer being root, etc.) Hmmm? The `signer' in this case is `Debian'. There should really be no need for non-Debian people to have root on master. To some extent sponsors are Debian people, too. The maximum security that the key can have on master is much less then what it can have on an individual's machine. Do you contest that? Mmm? One per .deb, YM? That's somewhere around 40 or 50 for each X upload. (each .deb has to be signed separately, no matter which way you do it) Use a piece of software that holds the passphrase (or unencrypted key) in memory for as long as the signing of all packages takes. I have exactly such a program in use, here. FWIW, I already stated that I'd rather have parts of Packages.gz signed by the responsible developers. Then, if one uploads 10 packages at once, one could just have this added to Packages.gz: -BEGIN xxx SIGNED MESSAGE- Package: foo1 [...] Package: foo2 [...] Package: foo10 [...] -BEGIN xxx SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE46IGV2sjtWDb/P1gRAuwvAKCFCLndF/PRfotCA+XHtht7GvQV2gCeO1iZ MfwN8JDj/vKOOCaUFNO0pPQ= =T8re -END xxx SIGNATURE- (s/PGP/xxx/ to protect MUAs that grep for these strings) This is very cliquey. Not everyone knows everyone else, even within Debian, let alone thinking about people who've never met a Debian developer in their lives. It would be an alternative, not a requirement. People can still go on as before. I probably should add a rider that it's already quite difficult to do this; developers machines aren't your regular `let's install RedHat 5.0 and leave all the default servers running', nor are most mirrors, and certainly most popular mirrors. Of course. The mirror I use runs Solaris ... hmm.
Re: Signing Packages.gz
On Sun, 2 Apr 2000, Julian Gilbey wrote: On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote: How many people foward ssh agents and put that key in their home .ssh/authorized_keys? What does that mean? It could easily be that I am doing something wrong without even realising it If you can ssh into your machine using RSA authentication and the key you use for that is in your ssh agent and you forward your agent then you can ssh from master back to your home machine without a password - and thus so can root. Jason
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote: On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote: But unfortunately that's not quite the choice I have either, since for some reason that I can't fathom, people seem to think that a dinstall key would be an abomination to man and God and I'd probably be summarily kicked out of the project as soon as I tried sending a patch somewhere. Or at least it'd never get applied. It seems you feel personally insulted. Not insulted, just frustrated. I am sorry for this, but unfortunately it doesn't change the situation that the signed packages case adds a further point of weakness to the chain of trust. And this is one of the reasons. It *leaves* a point of weakness in the chain of trust, it doesn't add any. 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're not very /convenient/, though. I was figuring to make them convenient enough to automate, you'd need to tack them on inside the .deb, like has been proposed in the past. You're welcome to correct this assumption, if you like. signed packages -- dinstall -- user 12 Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept truly[1] secret (it directly depends on the security of master), this weakness is rather huge. This problem is avoided if the link 1 is propagated to the users: I'm sorry, but that's a matter of opinion. If you're really *hugely* worried about the security of master, then please, show us your scripts that you've already had to write to cope with the fact that master's so insecure it's probably already compromised. Yes, it's a problem, but one you seem to be vastly overrating. signed packages -- dinstall \ 1 \-- user 1 Really, what we have is: maintainers -3-. | V 1users | ^ `-debian--2---' The first link is already checked completely. Debian knows that all the packages it distributes are created by developers. Link 2, which could be accurately implemented by signing Packages files and nothing more (and is hence really easy to do, really easy to automate and adds next to no overhead at all), allows a user to confidently say This distribution is Debian's. Hence, if Debian (ie, all our servers, some of our important people, whatever) gets compromised, they're stuffed, yes. Do think about that though: Debian gets compromised. That's not some J. Random Event that happens every day, every month, or every year. It's not something you can just blithely work around, either. People installing for the first time might be willing to trust www.debian.org to be controlled by Debian, but they're not going to have any other way of verifying the whole debian-keyring. If www.debian.org is compromised, there's no reason for them not to accept some bizarrely wrong keyring as gospel. Link 3, allows you to verify for yourself who built a particular package that Debian distributes. Or at least, allows you to verify the key they used. Verifying that they're an actual person, that they're really someone you have a reason to trust, and that they themselves haven't been compromised, is less trivial. (This is asserted by `Debian', but hey, like you say, Debian could be compromised. Who'd wanna trust them?) In this situation, I don't have to trust anyone except the Debian developer. Not the admin team, not the security team, not master, not dinstall. Can't you see that this is a crucial advantage? Can't you see that it's a crucial *flaw*? You have to trust *every* person who's a developer. And guess what. That means you have to trust the admin team and the security team. It means you have to assume that every machine every developer stores a secret key on is maintained as or more securely than master. If you also want a link 2 from dinstall to the user, I don't care. But don't tell the users that link 2 asserts that all packages come from Debian developers, it doesn't. No, it asserts that all packages come from *Debian*. Debian itself states that they'll only distribute packages that come from developers listed in the keyring; and yes, it might turn out that Debian as an organisation has been compromised, or hacked, or is just lying. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 03:38:29PM +0200, Marcus Brinkmann wrote: I could not trust either. The former, because it is stored on a network connected machine, the latter because it is transfered over the net (if it is shared among the security team). Of course, if the security team use their personal key in the latter case, I can trust it. Are you really sure that no developer stores their key on a net connected machine? Also, what's so fundamentally wrong with transferring a secret key over the net? Hint: PGP does it every time you send an encrypted email. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpI6fj63HQs1.pgp Description: PGP signature
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 10:36:44PM -0600, Zed Pobre wrote: Also, what's so fundamentally wrong with transferring a secret key over the net? Hint: PGP does it every time you send an encrypted email. Either you are using the phrase secret key in a context with which I am unfamiliar, or you do not understand PGP. PGP/GPG does not transfer your secret key component when encrypting a message to another. It is possible to encrypt a message to someone else's public key without *having* a secret key of your own in the first place. PGP (v2.x, I'm not uptodate with the recent OpenPGP stuff), generates a secret (albeit symmetric, rather than public/private keypair) IDEA key everytime you try to encrpt a message. It encrypts the message with this key, then encrypts the key with the recipients public key, and (and here's the bit I was referring to) *sends that secret IDEA key across the net*. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpS8YZqnjgrO.pgp Description: PGP signature
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 02:46:30PM +1000, Anthony Towns wrote: PGP (v2.x, I'm not uptodate with the recent OpenPGP stuff), generates a secret (albeit symmetric, rather than public/private keypair) IDEA key everytime you try to encrpt a message. It encrypts the message with this key, then encrypts the key with the recipients public key, and (and here's the bit I was referring to) *sends that secret IDEA key across the net*. But you might emphasize that this secret key is used exactly once, just for this message. Intercepting it won't allow you to sign other stuff as someone else. So equating the sending of this kind of secret key and leaving your private key on a server is comparing apples and oranges. -- The idea is that the first face shown to people is one they can readily accept - a more traditional logo. The lunacy element is only revealed subsequently, via the LunaDude. [excerpted from the Lunatech Identity Manual]
Re: Signing Packages.gz
On Sun, Apr 02, 2000 at 01:36:56PM +1000, Anthony Towns wrote: On Sat, Apr 01, 2000 at 03:38:29PM +0200, Marcus Brinkmann wrote: I could not trust either. The former, because it is stored on a network connected machine, the latter because it is transfered over the net (if it is shared among the security team). Of course, if the security team use their personal key in the latter case, I can trust it. Are you really sure that no developer stores their key on a net connected machine? No, but if I find out, I can investigate the installed packages or delete his key from my personal copy of the debian-keyring (and could configure the not-existing dpkg-verify software to use this smaller keyring), if I really cared. Do you see the difference? I can make an informed decision, while in the signed packages file case, I can not verfiy the origin of any of the packages I don't have the changes file for. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 02:49:40PM -0700, Jason Gunthorpe wrote: On Sat, 1 Apr 2000, Marcus Brinkmann wrote: In the signed .debs case, I, as a developer, assert that the package comes from me. A user can directly verify this by checking the signature. No, the user cannot verify that. The user can check the signature against our keyring but they have no idea who *should* have signed it. It seems to be hard to understand, so I will explain it one more time: Why do you think this is not true in the signed packages case? Because you only have one key to verify and trust, the dinstall key. In my case, there is also a single one key to trust: The key used to sign the debian-keyring package. To complete the analogy: You could sign the debian-keyring package with your dinstall secret key to reach the same effect. Only that we alread have a debian-keyring package, and no mechanism to sign Packages files. The signature on the Packages files corresponds the signature on the debian-keyrng package in some way. Both secret keys should be kept private, but it is easier with the latter, as it is a trusted maintainers package. If this ever changes, we need to publish a different public key to verify against, the same is true for the dinstall key. This means that all I need to do is nix one of our maintainers keys and I can undetectably forge Debian packages willy nilly. This is aside from the other problem of keeping 600 keys up to date on the client machines and making sure that huge keyring is not disturbed in transit. Oh yeah. I think if you are paranoid, you don't care about 500k additional bandwidth. Can you be more specific about the disturbed? I don't know of any valid attack that involves disturbing the transit? BTW, just to turn it around for the sake of argument: The Packages file is bigger than the debian-keyring. whatever comes from dinstall, but he can not directly check if what is in the archive comes really from the developers (not a problem if dinstall can be trusted). If we store the .changes files as I propose then the end use can check it, if they want. Yes, and it should be stored, and verificable automatically. But nobody will, because it is not a usefull thing to check. You say so. I disagree, and I think I gave sufficient arguments to show the opposite. Unfortunately, the people involved in this discussion are not interested in working out a good solution, but to win an argument. I don't have time for child games, sorry. The signed deb case not only has all the advantages of the signed packages file (there is almost a one to one correspondency, modulo location of the secret key (dinstall/debian-keyring)), it also allows verification of individual packages from a different source, which does not come with a packages file. It seems that people around here are happily throwing away an integrated solution in favour of a simple one. I doubt that the dinstall key will be stored secretly, and I doubt that the responsible people will tell the truth about this. This will lead to a false security by the user, and this is what I am concerned about. It has use to definitively verify the root archive (say, after a hacking or something) but otherwise the end user cannot make much use of it at all. The root of the packages are the developers, not master. The latter adds a chain, thus one further point of weakness. I might add that as the dinstall key can't be kept truly secret if it is stored on a net-connected machine, this weakness is rather huge. The dinstall and security keys (particularly the security key) are going to be far, far more secure than the weekest key in the key ring. It's a single point of failure, while maintainer keys only are applied to some packages. I could not trust either. The former, because it is stored on a network connected machine, the latter because it is transfered over the net (if it This is a flawed assertion - by your logic SSL is insecure and must not be used. In reality it is a perfectly good system that has really good security benifits. I don't know SSL, so, no comment. It does however serve a different purpose (encryption of streams, as opposed to verification of archives), so I doubt whatever is true for SSL is applicable to this discussion. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote: On Sat, 1 Apr 2000, Marcus Brinkmann wrote: Wrong. If you have signed debs, and you are careful when updating the debian-keyring package, there is no risk even if master is compromised. Hahha! Sorry, your are deluded if you belive this : Seriously, if someone can hack master we are all vunerable - how many people out there do you think use the same password on master as on their home boxes? How many people foward ssh agents and put that key in their home .ssh/authorized_keys? How many people have foolishly left their pgp key on master? Hint: Lots to all of the above [except the last, we purged a bunch of people for that awhile ago]. Ok, I was only looking at master as the ftp archive. I am happy that the the last is not true anymore. BTW, those people should be forced to use a new key to sign Debian packages. The SSL problems I don't know about. If master is compromized right now, we would take the d-changes archive from a more secure machine [which we may not even have, hence the interest in storing that in the archive], a slink cd, some potato CDs developers might have, etc, and begin painstakingly verfiying each and every .deb and .dsc to make sure it comes from where it was supposed to come from - there is no automated way to do this and only people like James would actually know who should be singing what packages. Yes, this is exactly my point. What would you do when you have signed Packages file and master is compromised? The attacker could replace some packages and create a new signed Packages file, just as dinstall does, and you had no way to find out after the mirrors catched up. In the signed deb case, you can easily verify all packages individually. (thanks for proving my point). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 03:18:17PM -0700, Jason Gunthorpe wrote: Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept truly[1] How about this, if someone was able to hack master to the point of being able to get the dinstall key, I assure you they would be able to hack some]weak developer machine and lift their key too. This is a seperate problem. I agree that this should not be the case, but it has no place in this discussion. If individual developer keys are compromised, we have a problem no matter what. Developers should not store secret keys on net connected machines, point. However, this only affects the developers packages, not the whole archive. I also assert that the chance of a hacker getting the security key is lower than say 50% of the keys in our keyring. I would not make such claims. In any way, see above. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
Hi, On Sun, Apr 02, 2000 at 01:33:53PM +1000, Anthony Towns 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. They're not very /convenient/, though. I was figuring to make them convenient enough to automate, you'd need to tack them on inside the .deb, like has been proposed in the past. You're welcome to correct this assumption, if you like. What you said is correct. signed packages -- dinstall -- user 12 Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept truly[1] secret (it directly depends on the security of master), this weakness is rather huge. This problem is avoided if the link 1 is propagated to the users: I'm sorry, but that's a matter of opinion. If you're really *hugely* worried about the security of master, then please, show us your scripts that you've already had to write to cope with the fact that master's so insecure it's probably already compromised. If you compare the security of PGP with the security of any linux machine, you will easily see the difference. PGP has been tested by thousands of people (experienced security experts), while every linux box has its own weak points. But already the complexity of a running system (which runs that many services as master does), is almost guaranteed to have an exploit. Yes, it's a problem, but one you seem to be vastly overrating. Are we talking about security, or are we talking about belief? I am very irritated that people who want to propose and implement a security measure for Debian packages are building on likeliness and probablility, and on the fact that master is quite secure. What about all the packages on other systems? Third party packages? Packages I build locally? There is a solution which covers individual debs even, where I don't know any more where they come from. signed packages -- dinstall \ 1 \-- user 1 Really, what we have is: maintainers -3-. | V 1users | ^ `-debian--2---' The first link is already checked completely. Debian knows that all the packages it distributes are created by developers. Yes, almost. It knows that all packages it accepts are created by developers. If the current packages in the archive are the one we uploaded, I can't know without messing around with the devel-changes archive :) Link 2, which could be accurately implemented by signing Packages files and nothing more (and is hence really easy to do, really easy to automate and adds next to no overhead at all), allows a user to confidently say This distribution is Debian's. Hence, if Debian (ie, all our servers, some of our important people, whatever) gets compromised, they're stuffed, yes. Yes. Does this not worry you? Do think about that though: Debian gets compromised. That's not some J. Random Event that happens every day, every month, or every year. It's not something you can just blithely work around, either. People installing for the first time might be willing to trust www.debian.org to be controlled by Debian, but they're not going to have any other way of verifying the whole debian-keyring. If www.debian.org is compromised, there's no reason for them not to accept some bizarrely wrong keyring as gospel. The debian-keyring signature is verified exactly in the same way as the dinstall key on the Packages file. Only that the debian-keyring keys secret key is stored securely on James machine (I hope), while the dinstall key is on a net connected machien and revealed to the attacker for free. Link 3, allows you to verify for yourself who built a particular package that Debian distributes. Or at least, allows you to verify the key they used. Verifying that they're an actual person, that they're really someone you have a reason to trust, and that they themselves haven't been compromised, is less trivial. (This is asserted by `Debian', but hey, like you say, Debian could be compromised. Who'd wanna trust them?) Debian is compromised, but you had to compromise James to get a fake key in. You are correct about the trust analysis. In this situation, I don't have to trust anyone except the Debian developer. Not the admin team, not the security team, not master, not dinstall. Can't you see
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 04:56:59PM -0700, Jason Gunthorpe wrote: On Sun, 2 Apr 2000, Julian Gilbey wrote: On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote: How many people foward ssh agents and put that key in their home .ssh/authorized_keys? What does that mean? It could easily be that I am doing something wrong without even realising it If you can ssh into your machine using RSA authentication and the key you use for that is in your ssh agent and you forward your agent then you can ssh from master back to your home machine without a password - and thus so can root. I think I understand now, thanks. In my case I had done this: On my home machine, I have an identity in .ssh/identity.pub. I copied that into .ssh/authorized_keys on master (possibly using the LDAP system). I *also* copied it into .ssh/authorized_keys on my home machine. That extra copy on my home machine (somehow) allows root to snoop my identity and so get into my home machine without a password. Solution: remove the identity from .ssh/authorized_keys on my home machine. If I were really paranoid, I ought to reinstall everything on my home machine in case I'd already been hacked. Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 10:48:54PM +0200, Marcus Brinkmann wrote: No. Currently there is NO chain of verification (I should not have said trust, it's the wrong term. Sorry). So you agree that it would be an improvement? However, it doesn't establish a complete chain of verification from the developers to the users, au contraire to what you seem to believe. Please don't tell me what I believe. I know that the solution is not perfect. But it's way better then what we have now. We already use link 1 (signed changes files), and trust it. This won't be changed by either proposal. Yes, even in the signed packages file you trust all developers keys. There is a difference between our master server trusting the uploaded changes files. master will by definition always have the current keyring. The user might not. Yes, but this doesn't change the point. The problem of out of date keys is a known problem in any public key cryptosystem. That it is a known problem does not change anything. It still IS a problem. While a developer might leave the project or even get thrown out the single dinstall key would by definition last until either Debian dies (hopefully this will not happen during my lifetime) or the key is compromised. In the latter case you can expect that all Linux news services will pick up it very soon. Okay - signing Packages will make Debian as secure as master is. Fine. We must assume that master is secure otherwise we are doomed anyway. Wrong. If you have signed debs, and you are careful when updating the debian-keyring package, there is no risk even if master is compromised. I made two points. Which is wrong? I don't think my first point is wrong. Signing packages will make Debian as secure as master is. The second point might or might not be wrong. Currently what happens if master is cracked? Right, we have a BIG problem. With the signed Packages file we still have a problem in that and only that case. But under the current setup we also have problem if our mirrors are cracked. It might even be possible to crack a few push primary mirrors and everybody will get a compromised Debian. We have to avoid this. This is the Debian way, right? Fetching the stick at the wrong end first. (Yes, this is a troll). No. The Debian problem is searching the optimal solution for too long and doing nothing in the meantime. We still have no perfect solution to improve our release cycles. So we did nothing. potato is not perfect so we don't release it. I wonder why you are working for the Hurd project then? You can't even run X11 Servers on the Hurd so why bother about it? The Linux kernel did not much when it was first released - but it did something. And you can improve it. What I have to admit is that I tend to make the same mistake. Remember, I wanted to fix GTK+ for the Hurd to not rely on MAXPATHLEN. There is an easy work around to make it work but I wanted to essentially rewrite the file selector. I still did not have the time to finish that while having a working (okay, working most of the time, it might fail with paths 4k) solution now would be better I think. Please stop retarding the efforts of other people because you think it is not perfect. Get on with your work and let Anthony and Jason implement the signed Packages.gz. Thanks Torsten PS: Did I say I will leave the project if we don't implement the signed Packages.gz? ;-)) -- Torsten Landschoff [EMAIL PROTECTED] [EMAIL PROTECTED] Debian Developer and Quality Assurance Committee Member pgpntESrWbvmA.pgp Description: PGP signature
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes: There is an existing single-point vulnerability in *every* mirror. Compromise the mirror and you can compromise every single Debian user who upgrades from that mirror. You don't even have to try touching anything at *.debian.org. Yes, and I'd very much see this vulnerability fixed. I just advocate that we could go the whole way, and make ourselves independent from the security of master, too. I think that is possible, but perhaps you can prove me wrong. For example, if you compromise master, you can pretend to just be the new-maintainer team and surreptitiously add yourself as a maintainer. Or you can pretend to be on the ftp team, and surreptitiously add or change existing package, and replace someone else's key with your own, say. I still won't get paranoid characters to trust my key. Let me rephrase that. This makes debian-keyring a base package, since if you want to verify the packages you download, you really want to do it right from the word go, rather than just some time later. That's to decide. This kind of security is optional. But yes, I'd recommend people to get the security-enabled base distribution. One problem here is that (depending on the US-export-regulations-du-jour) this base would qualify for non-US. Not very good. Of course some more complicated scheme could be built, which had base download and verify (by MD5) a corresponding base-secure addendum. More work. It's currently the case, yes, but it *could* be changed. You could, for example setup dinstall so that it wouldn't accept NMUs of certain important packages (such as gnupg). A good idea. Still: with package-granularity, this decision is made by the users, not the Debian administrators. And, equally, a deliberately compromised package would probably get a fair bit of coverage too. It'd be nice not have to rely on staying up to date with slashdot and the mailing lists and IRC before doing an apt-get dist-upgrade though. If you trust the debian-keyring maintainer, there is no problem for you: your keyring will get updated (to a version w/o the bad guy's key) and then any other packages get upgraded. People will probably also quickly updated packages compromised by this guy with fixed versions. The *reason* Debian handles security bugs (security leaks?) in packages well is that we have a mechanism for handling bugs, and we make use of it. The best way to ensure that we always have mechanisms for fixing things is to think about it first, not just handwave it away and say She'll be right, mate. I don't see how this doesn't apply to the bad maintainer scenario. If someone discovers a security bug in a package that has probably been put in deliberately, she should: 1) file a critical report against the package 2) Cc or otherwise inform this list, and state her suspicions If there is consensus that the maintainer put a backdoor in on purpose, he will get kicked, a new version of debian-keyring will be produced, and the situation is repaired. The highly trusted person you're referring to here is eash member of the new-maintainer team, by the way. This is a possibility, not a requirement. And if a developer gets kicked out? You can't revoke a signature (PGP signatures are designed to certify identity, not trustworthyness), [...] GPG can revoke signatures, so your conclusions do not apply. And again you have the usual problems if someone compromises one of the machines with this `super key' on it. Indeed. But this machine could be made more secure than the debian main machines could ever get (there's no need for people other than the signer being root, etc.) Corrupting the debian-keyring package is useless, [...] And if they corrupt this master key as well? Then we have a problem. Perhaps it's no use to put in another level of signing. Let's for now forget about the super-key, and make the debian-keyring package the thing to use. Again, all these complicated distributed methods are great and all, but they *aren't* actually particularly more secure, and nor are they more convenient. I don't think it would more complicated for developers. Perhaps one additional entering of their passphrase, while building the .changes file, but that's it. Users could choose their paranoia level. From trusting (same as now) to paranoid (only trust packages signed by a key which is signed by my own key). In some vague academic sense, they're harder to compromise *completely*, but I don't think that makes any particular exploits any harder to perform, practically speaking. I partly concur. Even if the developer-user channel was completely secured by signatures et al, we would still have the problem of an attacker gaining very much by breaking into a single developer's machine. You're netbase package is a good example: it contains a couple of programs usually started as root. If your developing machine is compromised, and your copy of the source
Re: Signing Packages.gz
Julian Gilbey [EMAIL PROTECTED] writes: On my home machine, I have an identity in .ssh/identity.pub. I copied that into .ssh/authorized_keys on master (possibly using the LDAP system). I *also* copied it into .ssh/authorized_keys on my home machine. That extra copy on my home machine (somehow) allows root to snoop my identity and so get into my home machine without a password. This is only possible if you used ssh-agent at some point, and had agent forwarding turned on at this time (this may be turned on by default). If you never use the agent, you're not at risk. Solution: remove the identity from .ssh/authorized_keys on my home machine. Note that *any* keys that your agent holds can be snarfed by the admin(s) of any hosts where you ssh-in with agent forwarding enabled. -- Robbe
Re: Signing Packages.gz
On 2 Apr 2000, Robert Bihlmeyer wrote: Solution: remove the identity from .ssh/authorized_keys on my home machine. Note that *any* keys that your agent holds can be snarfed by the admin(s) of any hosts where you ssh-in with agent forwarding enabled. No, that is the point of ssh-agent. The key never leaves your machine the authentication request travels through SSH to your agent, and then back again with the proper encrypted credentials. So long as your ssh is active an attacker can use that to access other machines you normally ssh into and presumably implant his own authorized_key. Jason
Re: Signing Packages.gz
Hi Marcus, On Sun, Apr 02, 2000 at 02:32:04PM +0200, Marcus Brinkmann wrote: No, the user cannot verify that. The user can check the signature against our keyring but they have no idea who *should* have signed it. It seems to be hard to understand, so I will explain it one more time: Why do you think this is not true in the signed packages case? Because you only have one key to verify and trust, the dinstall key. No, because the signatures on that packages are seen by Debian developers following -devel-changes as well as by the ftp admins. In my case, there is also a single one key to trust: The key used to sign the debian-keyring package. No, you also have to trust the maintainer who signed the package. There is no way for an end user to know how is maintaining a package without following -devel or somesuch or know if an NMU is okay. To complete the analogy: You could sign the debian-keyring package with your dinstall secret key to reach the same effect. Only that we alread have a debian-keyring package, and no mechanism to sign Packages files. We don't? Ever tried gpg -a --clearsign Packages.gz? The signature on the Packages files corresponds the signature on the debian-keyrng package in some way. Both secret keys should be kept private, but it is easier with the latter, as it is a trusted maintainers package. Why does that make keeping the key private easier? If this ever changes, we need to publish a different public key to verify against, the same is true for the dinstall key. We might want to revoke the old key. If James leaves we can't revoke his key because it is HIS key. We can however revoke the dinstall key because it is by definition Debian's key. But this is nitpicking. This is aside from the other problem of keeping 600 keys up to date on the client machines and making sure that huge keyring is not disturbed in transit. Oh yeah. I think if you are paranoid, you don't care about 500k additional bandwidth. Can you be more specific about the disturbed? I don't know of any valid attack that involves disturbing the transit? Break into a mirror and modify the debian-keyring package. For new installs this will be enough to break into a system. BTW, just to turn it around for the sake of argument: The Packages file is bigger than the debian-keyring. But you always need the Packages file anyway (if you are using apt that is). If we store the .changes files as I propose then the end use can check it, if they want. Yes, and it should be stored, and verificable automatically. Please tell me then how to verify the debian-keyring package? But nobody will, because it is not a usefull thing to check. You say so. I disagree, and I think I gave sufficient arguments to show the opposite. Unfortunately, the people involved in this discussion are not interested in working out a good solution, but to win an argument. I don't have time for child games, sorry. You have started the child game. We want to make a simple change to apt as dinstall and you keep telling us that it won't make things better. Now you said that making things better but not perfect is not the Debian way of doing things. I have to say I am glad that not all developers think this way. Otherwise we would still be discussing on debian-admintool how to implement a configuration manager. Did you notice that debconf was not perfect at first? It is still not perfect (my opinion) but it is working. And it is better than nothing. Regarding the argument: I do not care if we win this argument. If I'd be the project leader I would say let's just ignore you and implement what we are discussing. It would take much less time to do so instead of talking to a brick. Question is: Who can decide if we implement this? Jason? Richard? Manoj? Wichert? Why are we discussing this all the time anyway? The signed deb case not only has all the advantages of the signed packages file (there is almost a one to one correspondency, modulo location of the secret key (dinstall/debian-keyring)), it also allows verification of individual packages from a different source, which does not come with a packages file. Cool. We want this key to prove that the package actually originates from Debian and you are telling us it is better if it can come from somewhere else? It seems that people around here are happily throwing away an integrated solution in favour of a simple one. I doubt that the dinstall key will be stored secretly, and I doubt that the responsible people will tell the truth about this. This will lead to a false security by the user, and this is what I am concerned about. We are not telling our users currently how insecure Debian is. RedHat did have the single key from the start. You can verify RPMs. Tell them it's more insecure that what Debian has. Currently we have no security at all. Breaking into ftp.random.debian.org will suffice. It has use to definitively verify
Re: Signing Packages.gz
On Sun, 2 Apr 2000, Marcus Brinkmann wrote: This is a seperate problem. I agree that this should not be the case, but it has no place in this discussion. If individual developer keys are compromised, we have a problem no matter what. Developers should not store secret keys on net connected machines, point. However, this only affects the developers packages, not the whole archive. ^ GAH!? Don't you see that isn't true?? Look, a hack attempt would go like this. 1) Break root on master 2) Use that to break user account on developer victum (any will do) (Hint: I have already shown that torsten at least could be attacked quite easially) 3) Steal PGP key 4) Use stolen PGP to form new glibc package with trojan, sneak into archive using #1 If #1 is possible than #3 and #4 sure as heck will be too! Furthermore, this is lethal, it can effect both stable, unstable, distributed CDs - everything! What is worse, once you know it has happened - how do you determine which PGP key has been stolen? You have to *manualy* go through every single package and check the signer by hand to make sure it is all correct. Only someone very well versed in the ftp archive can do this. In fact, any time a developer is forced to revoke his key for any reason it calls the security of 'fixed' things we have distributed (stable basically) into question, you can't quite tell if that CD out there is legit or modified. This is a very serious weakness. Think about that, it is important. With a dinstall key it goes like this 1) Break root on master 2) Hack archive use dinstall key. However, an attacker doing this can only ruin unstable, our stable distribution and all CDs *remain secure* The archive itself is recoverable because the process above can be done. This is also very easially recoverable, we revoke the dinstall key, create a new one, signed by the security key and automated tools can fix the situation without hassle. The dinstall key has no permanance (on CDs on the like) so this isn't a big deal. With the secure dinstall key things are the best they can be: 1) Break root on wichert's machine 2) Steal security key 3) Break root on master or forge CD's Now we assume wichert is very carefull with the security key [more carefull than the average developer] so #2 is very very hard - thus this is the most secure alternative to the 2 above. But is impossible for use on a daily basis. Jason
Re: Signing Packages.gz
Chris Frey wrote: I'm curious how this issue is going to be handled now that it has been discussed. (The archives don't seem to be seeing any new messages on this topic.) What has to occur before this cryptographic signing of Packages actually happens? Oops, the recent mail archive update just showed a bunch of new messages. I was perhaps a bit hasty in declaring this discussed. :-) I'm eagerly watching this discussion to see how it turns out. Thanks to all who have taken my request so seriously! I really appreciate it. - Chris
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 01:24:03AM +0200, Marcus Brinkmann wrote: The whole file --- verifying each entry would take at least three minutes on my hardware, and god knows how long on anything moderately old or outdated. I certainly wouldn't want to try it on m68k on a regular basis, eg. (If doing something just once takes a second; doing it 4000 times takes a bit over an hour) I don't think it is useful to sign the Packages file, because: A signature authenticates the source of a document. That's worthwhile, since verifying the source of a Packages file lets you transitively verify the source of all the packages in a distribution. This is true if the signature is made in a secure manner. Storing the key on a medium that is available by dinstall is not secure, because a compromise of dinstall or higher instances (master etc) will reveal the secret key. `is not secure' is out and out FUD. It's no less secure, for example, than saying `hey, this public key up on www.debian.org is canonical for the keyring! check it!' because, hey, all you have to do to compromise it is to replace it with your own, which just involves hacking some .debian.org machine. If you want to just say `oh, I just trust every maintainer's secret key' you need to trust that *every* machine owned by *every* developer isn't equally compromised. If you want to just say `oh, I trust James' signature', you have to trust that *his* machine isn't compromised. I should probably add: these two options (signing Packages files automatically, and including a signature of the control and data portions of a .deb in with the .deb) don't have to be mutually exclusive at all. Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). Nonsense. So you agree with me. What exactly do you think is nonsense? The risk isn't nonsense, it's the implication that the risk is so completely abhorrent that we should thus continue with our current more-or-less lack of security instead, because it's better for our soul or something that's nonsense. If dinstall *isn't* compromised, it's still possible that your favourite FTP site is, in which case all they need to do to compromise your machine is replace a .deb with their own hacked version and let you download it. Yes, and I can decide if I should trust this package at installation time. I can base this decision on the keys in the Debian keyring package, and further information I get from the Debian web site etc. In your model, I can not perform these further tests. I would have to trust dinstall (and higher instances) completely, or loose. Which is a good reason to have both available. Note that in most cases dinstall will simply agree with your local tests. If the .deb's made by some creep, you won't know his signature, but he won' t have been able to upload to master anyway. What else might happen? * Someone resigned from Debian, and you've already done a partial upgrade and lost his key from debian-keyring, and want to install a new package from your out-of-date stable CD. Dinstall is better, because you can easily verify that at the time, this was legitimate. * Someone was kicked out of Debian and you're using an out of date keyring. Dinstall is better. (You're doing a partial upgrade, say. Ooops. Always remember to upgrade debian-keyring first) * James resigns. Someone else takes over debian-keyring. Dinstall is better. (Well, depending on whether its James you trust for signing things, or any developer in general. Also consider what would happen on a hamm-potato upgrade if James quit during potato, and the new debian-keyring maintainer only appeared during slink) * Someone cracks master, adds a package signed by them, adds their key to debian-keyring, and lets dinstall sign stuff. (Just checking dinstall is consistent, you're stuffed. Checking debian-keyring is signed by an existing developer, or signed by James himself, fails, and you're happy) * Someone cracks both a mirror, and a developer's key, and starts maintaining a .deb on that mirror, and stops debian-keyring from being updated. Dinstall is better. (with dinstall, they can only stop a mirror from being updated in its entirety, with debian-keyring, they can keep making new updates to whoever's packages, and no one need be any the wiser). Other things, like if someone cracks James' key while he's asleep, can be equally painful in both cases, of course. Automatically signing things is less secure than
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 12:15:01PM +1000, Anthony Towns wrote: (among many other minor typos) You can differentiated probably good but outdated old packages, and probably ^^ This should read can't differentiate. Whoops. bad but outdated old packages, no. On the upside, you can still verify that once upon a time they *were* trusted. You also can't verify whether they're still trusted now or not, assuming they're not from the current stable. Also, upon a little reflection, I might add... Let me be somewhat linear for a moment. This is what I'm claiming: current-system dinstall-key, signed-debs dinstall-key signed-debs ...that I'm more than happy to concede that, personally, for my circumstances, I believe: current-system dinstall-key signed-debs dinstall-key signed-debs If I had a choice between dinstall-key and signed-debs being implemented tomorrow, by someone else, with no work by me, especially with the proviso that only one of them would be done, ever, I'd choose signed-debs. But that's not the choice I have. The choice I have is that I *can* implement dinstall-keys, with probably a few days work, so that both apt and dinstall support it, most of which time would be spent working out how apt and dinstall are meant to work. I'm far less confident of being able to implement signed-debs; both because the dpkg code scares me, and getting the semantics of verification right (accepting signatures by any key from debian-keyring, but only keys from debian-keyring for most packages, and only James' key for debian-keyring) and working out how to update James in case he retires, scares me too. And not only this, but I can implement the former in the knowledge that it won't stop the latter from being done too. But unfortunately that's not quite the choice I have either, since for some reason that I can't fathom, people seem to think that a dinstall key would be an abomination to man and God and I'd probably be summarily kicked out of the project as soon as I tried sending a patch somewhere. Or at least it'd never get applied. So really, I have the choice between trying to convince people that giving dinstall a key of its own isn't actually as horrendous as people think, and that it's actually, to some extent, a Good Thing, or just learning to live with it. And thus this thread. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpuP0cOQIjGO.pgp Description: PGP signature
Re: Signing Packages.gz
On Sat, 1 Apr 2000, Anthony Towns wrote: I'm not sure why this isn't getting through. Automatically, cavalierly signing Packages.gz on master *HAS DEFINITE GAINS OVER THE PRESENT WAY OF DOING THINGS*. How exactly do you propose to transfer a verification key to the clients? I can't think of any decent way to do this that isn't prone to some kind of hack-a-mirror thing or involves annoying extra steps. You are wrong about signed .debs vs signed package files. Signed .debs are not worth the bytes to transfer a signature and the time check it. Their only real use is to check the master archive against hack/corruption and even that is better served by saving the uploading .changes file [preferably on multiple hosts, hence d-devel-changes]. In fact I would argue .deb sigs only give people a false sense of security because it makes the system as weak as the weakest key in our keyring. Signed package files on the other hand provide a really fast and efficient way to definately verify the whole chain, from us to the user. In particular, we could have a relatively insecure daily use dinstall key [for unstable] and a strong release key (aka the key the security team uses) When we do a release all the package files are signed using the security key and we have a nice sealed package that can be checked quickly and efficiently by the users. The trick however is to distribute the security key automatically and efficiently. [The dinstall key can be derived from this one] Ponder Ponder. Incidently the dinstall change is all of (basically) cd .../dists/unstable/ find -name Packages -or Packages.gz | xargs mymd5sum | gpg --clearsign Packages.sig stable would be signed once at each release time by the security team. APT would need to download this file, verify, then load the md5s internally for checking the package files. It would also have the nice side effect of providing accurate progress meters for package files (since you would want to include sizes in the index.). There are some tricky details about how to locate the .sig file for each package file, but that I think is fairly resolvable.. Jason
Re: Signing Packages.gz
On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote:
How exactly do you propose to transfer a verification key to the clients?
I can't think of any decent way to do this that isn't prone to some kind
of hack-a-mirror thing or involves annoying extra steps.
Just about everything is prone to the hack-a-mirror thing at the very
first point. If you hack-a-mirror and change James' key in debian-keyring,
and no one has a copy of debian-keyring already do compare it against,
you're stuck.
The dinstall key could be verified by:
* the web of trust, and having the ftp-team sign it
* putting a fingerprint on the website and in Debian books,
and making it easy for people to verify said fingerprint
* getting copies of the key from multiple sites, and checking that
all the copies you got are the same
None of these are completely foolproof, of course.
In
particular, we could have a relatively insecure daily use dinstall key
[for unstable] and a strong release key (aka the key the security team
uses) When we do a release all the package files are signed using the
security key and we have a nice sealed package that can be checked quickly
and efficiently by the users.
This key (or the private half thereof) wouldn't need to be anywhere near
any public machines, either.
The trick however is to distribute the security key automatically and
efficiently. [The dinstall key can be derived from this one] Ponder
Ponder.
Stick it on the ftp site, and use the web of trust. (If the secure-key that
you currently have trusts it, then it's good. Either because it's an update
of the old secure-key, or because it's an unstable-key).
`Using' the web of trust is probably easier said than done, though.
Incidently the dinstall change is all of (basically)
cd .../dists/unstable/
find -name Packages -or Packages.gz | xargs mymd5sum | gpg --clearsign
Packages.sig
I'd have done:
find -name Packages -o -name Sources -exec gpg --detach-sign --armor {} \
-o {}.gpg
or so before gzipping anything.
APT would need to download this file, verify, then load the md5s
internally for checking the package files.
I'd have made it download a Packages.gpg as well as Packages.gz and
Release, and if:
(a) Apt::Require-Gpg=true (or something) and: gpg isn't installed,
or the unstable key/security key doesn't exist, or
Packages.gpg doesn't exist
or (b) The .gpg isn't a signature of the Packages file by one of the
proper security or unstable keys
then die horribly.
Updating the key would need to be a completely separate operation to
downloading packages (it'd have to be done first, in case the keys
outdated, and it'd have to be verified differently).
Or at least, that's how I was toying with doing it a while ago, and
apart from not knowing how to make an Apt option, or wanting to do a
system call properly and elegantly (as opposed to using system()) it
was working fairly well.
Cheers,
aj
--
Anthony Towns [EMAIL PROTECTED] 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
pgpl2cfRXMxxI.pgp
Description: PGP signature
Re: Signing Packages.gz
On Sat, 1 Apr 2000, Anthony Towns wrote: * the web of trust, and having the ftp-team sign it The average user has no entry to the web of trust, so this is just as useless. (and massively involved for our poor end user) * putting a fingerprint on the website and in Debian books, and making it easy for people to verify said fingerprint This is probably the only thing we can do. This key (or the private half thereof) wouldn't need to be anywhere near any public machines, either. ? The dinstall daily key has to be on master and have no password. The securty key is kept by a handfull of people on their local machines who are rather panaroid. Stick it on the ftp site, and use the web of trust. (If the secure-key that you currently have trusts it, then it's good. Either because it's an update of the old secure-key, or because it's an unstable-key). The security key must never be obsoleted, it should last the life time of the project - anything else is too complicated for our users :| or so before gzipping anything. I'd like a seperate global index, that is much more usefull really. Jason
Re: Signing Packages.gz
On Fri, Mar 31, 2000 at 09:31:31PM -0700, Jason Gunthorpe wrote: On Sat, 1 Apr 2000, Anthony Towns wrote: * the web of trust, and having the ftp-team sign it The average user has no entry to the web of trust, so this is just as useless. (and massively involved for our poor end user) It's useful for a lot of people though (although nowhere near most). People who're friends of a guy who's in a usergroup with a guy who went to a conference that a developer went to who's also met someone on the security team should theoretically be able to just say gpg --somethingorother and get a list of the trust path, and a bright little message that says `Hey, you have reason to trust this person, well done!'. I don't know that gpg has such an option atm though, or whether the keyservers are setup appropriately for such an operation to be really feasible. But there's little cost from our end to make it possible at least. Stick it on the ftp site, and use the web of trust. (If the secure-key that you currently have trusts it, then it's good. Either because it's an update of the old secure-key, or because it's an unstable-key). The security key must never be obsoleted, it should last the life time of the project - anything else is too complicated for our users :| Not really possible. If one of the security team dies, or their equipment gets stolen, or Quantum computing takes off, or... Heaps of things can invalidate a key. The security one ought to last a few releases at least though, enough so that manual reverification isn't too horrible. Why would verifying a new security-key necessarily be significantly harder than verifying a new unstable-key, though? In both cases you only really want to check that its signed by the previous security-key. or so before gzipping anything. I'd like a seperate global index, that is much more usefull really. A global index wouldn't be entirely appropriate for partial mirrors. *shrug* How would you go about signing half of a global index with the unstable key, and leaving the rest signed by the security key? Having a new file right next to the old Packages.gz file might be easier to ensure mirroring too. I'm not sure where you'd put a global, signed index? *shrug* You could have both, if you wanted, too, I guess. How would the index be particularly more useful? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpNROB65eklQ.pgp Description: PGP signature
Re: Signing Packages.gz
On Sat, 1 Apr 2000, Anthony Towns wrote: Why would verifying a new security-key necessarily be significantly harder than verifying a new unstable-key, though? In both cases you only really want to check that its signed by the previous security-key. But in the other case it replaces/augements the security key, having an automatic means for that seems like a bad idea. A global index wouldn't be entirely appropriate for partial mirrors. *shrug* The file would be small, people can mirror it too. Partial mirrors are going to need more and more special care in the future that I don't think this is a concern. How would you go about signing half of a global index with the unstable key, and leaving the rest signed by the security key? Two indexes each signed by their respective keys, and the two keys. Having a new file right next to the old Packages.gz file might be easier to ensure mirroring too. I'm not sure where you'd put a global, signed index? *shrug* debian/indices with the rest of that stuff. You could have both, if you wanted, too, I guess. How would the index be particularly more useful? I've always wanted an index : It is simpler to work with and faster overall (two gpg checks vs ~36, gpg is very very slow). It also would have file sizes, I like file sizes : Jason
Re: Signing Packages.gz
Hi, I'm curious how this issue is going to be handled now that it has been discussed. (The archives don't seem to be seeing any new messages on this topic.) What has to occur before this cryptographic signing of Packages actually happens? Does it need to become part of policy? (in which case I kiss this idea good-bye as lost in the black-hole of bureaucracy?) Does it need support software in apt? dpkg? something else? (in which case I anxiously await for some developer to code this, or provide patches of my own which may never get applied?) Could it be added to a script during this dinstall process? Or is somebody already working on it and I just haven't heard? I'm sure I'm showing my ignorance of how things work around here, but this is one issue that I really don't want forgotten about. And from some comments I've seen, it shouldn't be that hard to implement. Is there something I can do to help? Helping you guys fix this would be a way-better use of my time than compiling everything by hand. Please don't let this die... - Chris P.S. And if somebody tells me to wait for woody, I'm gonna have to lose my mind. :-)
Re: Signing Packages.gz
On Fri, Mar 31, 2000 at 08:22:14PM -0700, Jason Gunthorpe wrote: You are wrong about signed .debs vs signed package files. Signed .debs are not worth the bytes to transfer a signature and the time check it. Their only real use is to check the master archive against hack/corruption and even that is better served by saving the uploading .changes file [preferably on multiple hosts, hence d-devel-changes]. In fact I would argue .deb sigs only give people a false sense of security because it makes the system as weak as the weakest key in our keyring. Signed package files on the other hand provide a really fast and efficient way to definately verify the whole chain, from us to the user. I can't follow your reasoning. In the signed .debs case, I, as a developer, assert that the package comes from me. A user can directly verify this by checking the signature. In the signed packages file case, I as a developer, assert that the package comes from me, which is verified by dinstall. Then the user verifies whatever comes from dinstall, but he can not directly check if what is in the archive comes really from the developers (not a problem if dinstall can be trusted). The latter adds a chain, thus one further point of weakness. I might add that as the dinstall key can't be kept truly secret if it is stored on a net-connected machine, this weakness is rather huge. You already trust the maintainers (either directly or through dinstall). What makes you think that adding a middleman improves the situation? In particular, we could have a relatively insecure daily use dinstall key [for unstable] and a strong release key (aka the key the security team uses) I could not trust either. The former, because it is stored on a network connected machine, the latter because it is transfered over the net (if it is shared among the security team). Of course, if the security team use their personal key in the latter case, I can trust it. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
Hi, On Sat, Apr 01, 2000 at 12:55:53PM +1000, Anthony Towns wrote: But unfortunately that's not quite the choice I have either, since for some reason that I can't fathom, people seem to think that a dinstall key would be an abomination to man and God and I'd probably be summarily kicked out of the project as soon as I tried sending a patch somewhere. Or at least it'd never get applied. It seems you feel personally insulted. I am sorry for this, but unfortunately it doesn't change the situation that the signed packages case adds a further point of weakness to the chain of trust. You are correct that both systems can be applied. Signing debs verifies that a package comes from a (probably former, if keyring is out of date) developer. Signing Packages verifies that the contained packages come from master. 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: signed packages -- dinstall -- user 12 We already use link 1 (signed changes files), and trust it. This won't be changed by either proposal. Yes, even in the signed packages file you trust all developers keys. Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept truly[1] secret (it directly depends on the security of master), this weakness is rather huge. This problem is avoided if the link 1 is propagated to the users: signed packages -- dinstall \ 1 \-- user 1 In this situation, I don't have to trust anyone except the Debian developer. Not the admin team, not the security team, not master, not dinstall. Can't you see that this is a crucial advantage? If you also want a link 2 from dinstall to the user, I don't care. But don't tell the users that link 2 asserts that all packages come from Debian developers, it doesn't. What link 2 asserts instead is that the packages come from master. It solves the mirror problem, but does not solve the master problem. I don't object to a signed Packages file, but it is important to see which problem it solves and which it doesn't solve. Also it is important to realize that the secret key automatically used by dinstall can not be stored in a highly secure way. Thanks, Marcus [1] As secret as any PGP key should be kept. -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Tue, Mar 28, 2000 at 12:41:22AM -0500, Chris Frey wrote: Quoting from the mailing list archives... :-) Marcus Brinkmann [EMAIL PROTECTED] wrote: On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: The whole file --- verifying each entry would take at least three minutes I don't think it is useful to sign the Packages file, because: Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). Can someone explain to me why any such key would have to be considered insecure? If it is accesible by dinstall, it has to be stored on masyer a machine connected to master. Hack master, and you get the secret key and you can tamper with it the way you want. If we are trusting the admin folks to generate the Packages file itself, can't we trust them to sign it properly? We could. However, we can make it so that we don't need to trust the at all, only individual developers. Is there another avenue that I can't see where this key could be compromised? It can not be compromised per se. However, it is subject to the same security as master is, which is much less than it should be (read the pgp docs to find out how a secret pgp key should be stored and used). And by the way, how do the paranoid people do things now? I don't know. I am not paranoid. Do they compile everything from source? This is one solution. The source is the only place I can find a signature at all, and this is the path I am currently venturing out on. yes. However, we already have the signatues on binary packages in the changes file. We just need to propagate it to our users. Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote: It seems you feel personally insulted. I am sorry for this, but unfortunately it doesn't change the situation that the signed packages case adds a further point of weakness to the chain of trust. Interesting. So signing Packages.gz will lower the security? I don't see the point. We can quite easily sign our Packages files without much effort and I think it would greatly increase the security of our mirrors. It's not a perfect solution but it is better than our current setup. If you ask me we should do it. ASAP. We already use link 1 (signed changes files), and trust it. This won't be changed by either proposal. Yes, even in the signed packages file you trust all developers keys. There is a difference between our master server trusting the uploaded changes files. master will by definition always have the current keyring. The user might not. Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept truly[1] secret (it directly depends on the security of master), this weakness is rather huge. This problem is avoided if the link 1 is propagated to the users: Okay - signing Packages will make Debian as secure as master is. Fine. We must assume that master is secure otherwise we are doomed anyway. Currently Debian is as secure as the worst maintained mirror. What link 2 asserts instead is that the packages come from master. It solves the mirror problem, but does not solve the master problem. So let's fix the mirror problem and let the master problem for later. I don't object to a signed Packages file, but it is important to see which problem it solves and which it doesn't solve. Also it is important to realize that the secret key automatically used by dinstall can not be stored in a highly secure way. I would say that the proposal that Jason made sounds good. Have a low-security key on master which is used to automatically sign the Packages (of course you would need to breach the account dinstall is running with or become root to read that private key). Then let our security team sign the stable releases. That keys are kept private on their machines. Thanks Torsten -- Torsten Landschoff [EMAIL PROTECTED] [EMAIL PROTECTED] Debian Developer and Quality Assurance Committee Member pgpoDrfqdDKF4.pgp Description: PGP signature
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 08:52:36PM +0200, Torsten Landschoff wrote: On Sat, Apr 01, 2000 at 04:00:20PM +0200, Marcus Brinkmann wrote: It seems you feel personally insulted. I am sorry for this, but unfortunately it doesn't change the situation that the signed packages case adds a further point of weakness to the chain of trust. Interesting. So signing Packages.gz will lower the security? No. Currently there is NO chain of verification (I should not have said trust, it's the wrong term. Sorry). However, it doesn't establish a complete chain of verification from the developers to the users, au contraire to what you seem to believe. We already use link 1 (signed changes files), and trust it. This won't be changed by either proposal. Yes, even in the signed packages file you trust all developers keys. There is a difference between our master server trusting the uploaded changes files. master will by definition always have the current keyring. The user might not. Yes, but this doesn't change the point. The problem of out of date keys is a known problem in any public key cryptosystem. Okay - signing Packages will make Debian as secure as master is. Fine. We must assume that master is secure otherwise we are doomed anyway. Wrong. If you have signed debs, and you are careful when updating the debian-keyring package, there is no risk even if master is compromised. Currently Debian is as secure as the worst maintained mirror. What link 2 asserts instead is that the packages come from master. It solves the mirror problem, but does not solve the master problem. So let's fix the mirror problem and let the master problem for later. This is the Debian way, right? Fetching the stick at the wrong end first. (Yes, this is a troll). Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sat, 1 Apr 2000, Marcus Brinkmann wrote: In the signed .debs case, I, as a developer, assert that the package comes from me. A user can directly verify this by checking the signature. No, the user cannot verify that. The user can check the signature against our keyring but they have no idea who *should* have signed it. This means that all I need to do is nix one of our maintainers keys and I can undetectably forge Debian packages willy nilly. This is aside from the other problem of keeping 600 keys up to date on the client machines and making sure that huge keyring is not disturbed in transit. whatever comes from dinstall, but he can not directly check if what is in the archive comes really from the developers (not a problem if dinstall can be trusted). If we store the .changes files as I propose then the end use can check it, if they want. But nobody will, because it is not a usefull thing to check. It has use to definitively verify the root archive (say, after a hacking or something) but otherwise the end user cannot make much use of it at all. The latter adds a chain, thus one further point of weakness. I might add that as the dinstall key can't be kept truly secret if it is stored on a net-connected machine, this weakness is rather huge. The dinstall and security keys (particularly the security key) are going to be far, far more secure than the weekest key in the key ring. I could not trust either. The former, because it is stored on a network connected machine, the latter because it is transfered over the net (if it This is a flawed assertion - by your logic SSL is insecure and must not be used. In reality it is a perfectly good system that has really good security benifits. Jason
Re: Signing Packages.gz
On Sat, 1 Apr 2000, Marcus Brinkmann wrote: Wrong. If you have signed debs, and you are careful when updating the debian-keyring package, there is no risk even if master is compromised. Hahha! Sorry, your are deluded if you belive this : Seriously, if someone can hack master we are all vunerable - how many people out there do you think use the same password on master as on their home boxes? How many people foward ssh agents and put that key in their home .ssh/authorized_keys? How many people have foolishly left their pgp key on master? Hint: Lots to all of the above [except the last, we purged a bunch of people for that awhile ago]. If master is compromized right now, we would take the d-changes archive from a more secure machine [which we may not even have, hence the interest in storing that in the archive], a slink cd, some potato CDs developers might have, etc, and begin painstakingly verfiying each and every .deb and .dsc to make sure it comes from where it was supposed to come from - there is no automated way to do this and only people like James would actually know who should be singing what packages. Jason
Re: Signing Packages.gz
On Sat, 1 Apr 2000, Marcus Brinkmann wrote: We already use link 1 (signed changes files), and trust it. This won't be changed by either proposal. Yes, even in the signed packages file you trust all developers keys. We only trust link1 due to the vigilance of our FTP masters and people reading -changes lists to make sure that, say, glibc is not uploaded by someone other than Joel. That is a critical part of the trust in that step. Now link 2. It is currently absent. What you seem to suggest is to add a key (dinstall-key) here, so the user can verify the archive. This adds a point of weakness. As the dinstall key can't be used automatically and kept truly[1] How about this, if someone was able to hack master to the point of being able to get the dinstall key, I assure you they would be able to hack some]weak developer machine and lift their key too. I also assert that the chance of a hacker getting the security key is lower than say 50% of the keys in our keyring. Furthermore it is comparitively easy to revoke a dinstall key - much harder to detect and revoke individual keys. What link 2 asserts instead is that the packages come from master. It solves the mirror problem, but does not solve the master problem. The master problem cannot be solved in an automatic fashion, it will always require skilled intervention by a human. Jason
Re: Signing Packages.gz
On Sat, Apr 01, 2000 at 03:16:23PM -0700, Jason Gunthorpe wrote: How many people foward ssh agents and put that key in their home .ssh/authorized_keys? What does that mean? It could easily be that I am doing something wrong without even realising it Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer, see http://www.debian.org/~jdg Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: Signing Packages.gz
Hi Anthony, On Mon, Mar 27, 2000 at 08:37:10AM +1000, Anthony Towns wrote: On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote: On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: The whole file --- verifying each entry would take at least three minutes on my hardware, and god knows how long on anything moderately old or outdated. I certainly wouldn't want to try it on m68k on a regular basis, eg. (If doing something just once takes a second; doing it 4000 times takes a bit over an hour) I don't think it is useful to sign the Packages file, because: A signature authenticates the source of a document. That's worthwhile, since verifying the source of a Packages file lets you transitively verify the source of all the packages in a distribution. This is true if the signature is made in a secure manner. Storing the key on a medium that is available by dinstall is not secure, because a compromise of dinstall or higher instances (master etc) will reveal the secret key. Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). Nonsense. The only reason not to trust a key dinstall uses explicitly for signing Packages is if you believe dinstall is compromised. If you believe that, then you shouldn't be downloading .deb's *ever*, because you're immediately running *untrusted* scripts as root on your systems. So you agree with me. What exactly do you think is nonsense? If dinstall *isn't* compromised, it's still possible that your favourite FTP site is, in which case all they need to do to compromise your machine is replace a .deb with their own hacked version and let you download it. Yes, and I can decide if I should trust this package at installation time. I can base this decision on the keys in the Debian keyring package, and further information I get from the Debian web site etc. In your model, I can not perform these further tests. I would have to trust dinstall (and higher instances) completely, or loose. Automatically signing things is less secure than manually signing things, It is only as secure as dinstall/master is, so we gain nothing at all by your suggestion. Here is a huge difference between your and my suggestion. What I proposed has problems (and I will address the problems you raised below), but it is a real improvement at least. and you need to do some extra stuff to not have gaping security holes when automatically signing things, but sometimes there isn't that much of a choice. There is in this case. All this FUD about no, no, we can't do that, it's not secure! is, well, just that. *Nothing* is absolutely `secure', some things just have fewer or different exploits than others. Wrong. The issue is not the degree of secureness in real life, where you hope that the few exploits won't be found. What we should be concerned about is theoretical secureness. Security models matter. There doesn't really seem a huge amount of choice here, to me. Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. There was some discussion about this in the past. The trick is that security should be implemented in dpkg(-dev), not somewhere else. This has the advantage that it works also with individual packages you don't get from an archive source. It cuold also be used to verify the origin of the package. Note that this makes debian-keyring a more or less standard package. Only if you care about security. Note that it requires you to trust everyone in that keyring with every aspect of your system. Well, this is already the case, and can't be prevented for a binary distribution. However, a little bit more exact is that you trust everyone in that keyring with every aspect of the package I install from a single person (if I don't trust someone, I can simply choose not to install the packages from this origin.). Of course, one package, however small, can ruin the whole system in its scripts, binaries etc. Note that this doesn't help with revoking signatures: if some idiot decides that being a Debian maintainer should give him the right to 0wn all the machines that use his package; then gets thrown out; he can still use his key to sign packages that'll be happily installed by anyone with an out of date debian-keyring. This is a valid concern, and it is directly inherited from the PGP security model. There is no way to avoid it, but it can be made small: In such cases, the new debian keyring should be advocated widely and added to the stable release as a security update (and appear on the web pages of course). BTW, there is an analogue concern in your model, and it is
Re: Signing Packages.gz
On Wed, Mar 29, 2000 at 01:12:39PM +0200, Robert Bihlmeyer wrote:
Well, it'd be nice to be able to do so, to verify that a mirror hasn't
been compromised, but no, you're right.
Actually I don't care that much if the mirror is compromised, if it
affects only packages that I don't install.
It would be nice for a compromised mirror to be able to easily work out
which packages were compromised.
Actually, now I think about it, the Packages file itself is valuable
information. Consider a Packages file that doesn't actually changes the
.deb's, but changes the netbase entry, say to read:
Package: netbase
Depends: vim
Conflicts: nvi, emacsen
and leaves everything else the same.
Nice one. Though, not possible the way I envision the signed
Packages.gz. Imagine the following:
Which, again, is not a method that I, at least, have ever seen proposed
before.
Package: cvs
Version: 1.10.7-7
Priority: optional
[...]
installed-size: 944
Signature-DSS: @[EMAIL PROTECTED])N871I=F4@:6YF;RUF:6QE('9I97=E@H`
It has quite a few problems. The first is that it's not in a format
that tools can (currently) process easily. That's likely to kill it
straight away. (By `easily' I mean, writing a tidy ten line shell script
that'll verify a given Packages entry).
Another is that these signatures are not currently made by
maintainers. That means you need to get every maintainer, and every porter
to manually recheck and re-sign and possibly reupload all their packages.
Another is that this doesn't cope with the fact that Packages files are
generated both from the .deb's themselves and from the overrides file
(which has the correct sections and priorities of .debs, as opposed
to what's listed in the .debs themselves) --- the Packages file isn't
the combined responsibility just of a bunch of maintainers it's the
responsibility of dinstall on master too.
Another problem is that maintaining these signatures would require changing
the way dinstall operates significantly.
Basically, it doesn't strike me as very practical.
The `Signature-DSS' field contains a signature over all the fields,
excluding itself. Since this includes the MD5sum, the package content
can't be corrupted. But this also protects the package metadata.
Another difficulty (one that's not overly difficult to resolve, but could
be awkward implementation-wise) is that you'll need to specify an order
to your fields for this.
Speaking about `more secure than the debian machines themselves' is
meaningless. If you can compromise the debian machines themselves,
you're home and hosed. You can do anything and everything.
Not true! If you have a trusted key of a developer,
If you have the trusted key of a trusted developer even, you can't verify
that some guy in Azerbaijan is actually a developer or not. The Debian
web of trust isn't connected.
And what about all those people that haven't ever met a developer
in person? Should they just buy RedHat instead?
no amount of
fiddling with the debian machines could corrupt the source packages
this developer uploaded without you noticing.
Congratulations. You can be completely confident xtictactoe hasn't been
compromised.
And again, what happens if a maintainer who's kicked out doesn't want to
admit the fact? He's still in the web of trust, and if he can compromise
a mirror (which may well have been the /reason/ he was kicked out), he
can make sure the updated debian-keyring never makes its way to you, and
insert his own hax0red but signed packages into pub/debian/dists. With
a completely signed Packages.gz the best he can do is make you miss out
on getting upgrades.
Note that this isn't *much* of a vulnerability: his PGP key's already been
linked with his real-life identity by Debian, and his hacked packages have
been signed with his PGP key, so there could easily be repurcussions, but
it's still an /avoidable/ risk.
No, it doesn't. And what would such a mirror actually *do*? Just mirror
master as it gets compromised, and end up compromised itself?
The premise was that master is not easily compromised (and if it is,
we're hosed anyway at the moment).
If master is not easily compromised then there isn't a concern with having
dinstall have a PGP key.
But remember that users can't
download from master, they have to use a by definition less secure
mirror. A direct mirror under the auspices of the Debian admin-team
would be a possibility for users to get it straight from the horse's
mouth.
Do you mean like ftp.debian.org?
The machine that can barely cope with the huge number of downloads
and connections? The machine that has trouble finding sponsors because
it uses more bandwidth than some not-particularly-small ISPs?
Now, we seem to have established that master can be considered
reasonably secure. What, exactly, is the /problem/ with having a single
widely-publicised `dinstall' key that automatically signs the various
Packages files? Where, exactly, is the
Re: Signing Packages.gz
Robert Bihlmeyer [EMAIL PROTECTED] wrote: That's just the point: the security of a singly-signed Packages.gz would not be much higher than that of the ftp sites themselves. Nothing to win, here. Actually I'm not concerned right now with the security of the main debian ftp site. While that's important, I assume that has already been handled. I just want to make sure that the packages I download come from Debian and not some man-in-the-middle. I can do that now on a maintainer level by using the source. But I cannot check that the binary I got really came from Debian people. And if Packages is signed, I would expect whoever or whatever signs it to also check that the packages listed inside that file actually came from a Debian maintainer. As far as I understand it, this is possible since the package upload (binary) is also signed by the maintainer. It seems like the only path that does not have at least some cryptographic safety is the path from Debian to the poor user. :-) And I hope Potato's Packages file can be signed so I don't have to wait for Woody. Even if I have to manually download the Packages file, check the signature, then update my system - even that will save me *hours* of work! - Chris
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes:
Well, it'd be nice to be able to do so, to verify that a mirror hasn't
been compromised, but no, you're right.
Actually I don't care that much if the mirror is compromised, if it
affects only packages that I don't install. If it affects some of
those packages, I will notice and alert the mainainer.
Actually, now I think about it, the Packages file itself is valuable
information. Consider a Packages file that doesn't actually changes the
.deb's, but changes the netbase entry, say to read:
Package: netbase
Depends: vim
Conflicts: nvi, emacsen
and leaves everything else the same.
Nice one. Though, not possible the way I envision the signed
Packages.gz. Imagine the following:
Package: cvs
Version: 1.10.7-7
Priority: optional
[...]
installed-size: 944
Signature-DSS: @[EMAIL PROTECTED])N871I=F4@:6YF;RUF:6QE('9I97=E@H`
Package: cvs-buildpackage
[...]
Signature-DSS: L5')Y(!U=65N8V]D92`M+6AE;'`G(9OB!M;W)E(EN9F]R;6%T:[EMAIL
PROTECTED]
etc.
The `Signature-DSS' field contains a signature over all the fields,
excluding itself. Since this includes the MD5sum, the package content
can't be corrupted. But this also protects the package metadata.
Per-package signatures would naturally accompany the package, not the
Packages.gz file.
No, see above.
Speaking about `more secure than the debian machines themselves' is
meaningless. If you can compromise the debian machines themselves,
you're home and hosed. You can do anything and everything.
Not true! If you have a trusted key of a developer, no amount of
fiddling with the debian machines could corrupt the source packages
this developer uploaded without you noticing. Because .dsc files are
signed by their maintainer's key. This won't work for binary packages,
though. And that could be changed.
No, it doesn't. And what would such a mirror actually *do*? Just mirror
master as it gets compromised, and end up compromised itself?
The premise was that master is not easily compromised (and if it is,
we're hosed anyway at the moment). But remember that users can't
download from master, they have to use a by definition less secure
mirror. A direct mirror under the auspices of the Debian admin-team
would be a possibility for users to get it straight from the horse's
mouth.
Huh? .debs are never created and uploaded without any intervention,
as I understand it. Including ports.
Aha. Sorry for being ignorant. So per-package signing could use either
the maintainer's key, or the porter's. It would have been a problem if
building port had been automated.
--
Robbe
Re: Signing Packages.gz
Quoting from the mailing list archives... :-) Marcus Brinkmann [EMAIL PROTECTED] wrote: On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: The whole file --- verifying each entry would take at least three minutes I don't think it is useful to sign the Packages file, because: Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). Can someone explain to me why any such key would have to be considered insecure? If we are trusting the admin folks to generate the Packages file itself, can't we trust them to sign it properly? Is there another avenue that I can't see where this key could be compromised? And by the way, how do the paranoid people do things now? (since I would like to be one of those people :-) ) Do they compile everything from source? The source is the only place I can find a signature at all, and this is the path I am currently venturing out on. Thanks for your responses! - Chris -- --- Chase the dream, not the competition. - motto of the Nemesis Air Racing Team
Re: Signing Packages.gz
On Tue, Mar 28, 2000 at 12:43:32AM +1000, Anthony Towns wrote: Actually, now I think about it, the Packages file itself is valuable information. Consider a Packages file that doesn't actually changes the .deb's, but changes the netbase entry, say to read: Package: netbase Depends: vim Conflicts: nvi, emacsen and leaves everything else the same. You can only achieve fairly petty vadalism with this, but it would still be nice to avoid it, IMO. What a deliciously evil idea. -- G. Branden Robinson|Reality is what refuses to go away when Debian GNU/Linux |I stop believing in it. [EMAIL PROTECTED] |-- Philip K. Dick roger.ecn.purdue.edu/~branden/ | pgpoJuI7bSUeY.pgp Description: PGP signature
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes: The only reason not to trust a key dinstall uses explicitly for signing Packages is if you believe dinstall is compromised. If you believe that, then you shouldn't be downloading .deb's *ever*, because you're immediately running *untrusted* scripts as root on your systems. That's just the point: the security of a singly-signed Packages.gz would not be much higher than that of the ftp sites themselves. Nothing to win, here. All this FUD about no, no, we can't do that, it's not secure! is, well, just that. *Nothing* is absolutely `secure', some things just have fewer or different exploits than others. Of course. But implementing a scheme that does give only marginally more security may not be worth the effort. Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. Note that this makes debian-keyring a more or less standard package. Either that, or just let dpkg Recommend it. If it is not installed, package verification is not available. Note that it requires you to trust everyone in that keyring with every aspect of your system. That's already the case, isn't it? Signed packages give you the benefit, that you'll *only* have to trust the maintainers you install packages from - not every man-in-the-middle. Note that this doesn't help with revoking signatures: if some idiot decides that being a Debian maintainer should give him the right to 0wn all the machines that use his package; then gets thrown out; he can still use his key to sign packages that'll be happily installed by anyone with an out of date debian-keyring. Indeed. But I am sure that this fact will get big coverage on the lists and the websites. Debian has handled security leaks in other packages well - this is just a leak in the package system that updating debian-keyring will plug, nothing else. If he can gain control of an ftp mirror, he can keep updating the debian-keyring.deb to include his key, and keep maintaining any packages he likes. No, see below. It also leads to something of a chicken-and-egg situation. It's much easier to verify a *single* key than that every one of five-hundred of the things is uncompromised. (It can be signed by previous versions of itself, it can be widely published in Debian books, it can be signed by the ftp team, etc) The solution is to have one master key (in the hands of a highly trusted person) that is treated like your single key (published everywhere). Every developer's key has to be signed by at least by this key. If one trusts this key, the confidence into keys signed by it is quite high. Additionally, I can verify keys by other means (e.g. those of developers living in my vicinity). Corrupting the debian-keyring package is useless, since the attacker will not be able to put valid (signed by master) keys into it. -- Robbe
Re: Signing Packages.gz
On Mon, Mar 27, 2000 at 12:17:47PM +0200, Robert Bihlmeyer wrote: Anthony Towns aj@azure.humbug.org.au writes: The only reason not to trust a key dinstall uses explicitly for signing Packages is if you believe dinstall is compromised. If you believe that, then you shouldn't be downloading .deb's *ever*, because you're immediately running *untrusted* scripts as root on your systems. That's just the point: the security of a singly-signed Packages.gz would not be much higher than that of the ftp sites themselves. Nothing to win, here. Pay attention. There is an existing single-point vulnerability in *every* mirror. Compromise the mirror and you can compromise every single Debian user who upgrades from that mirror. You don't even have to try touching anything at *.debian.org. That is the vulnerability being addressed, not anything else. And note that the vulnerability you quoted above is decidedly difficult to avoid. For example, if you compromise master, you can pretend to just be the new-maintainer team and surreptitiously add yourself as a maintainer. Or you can pretend to be on the ftp team, and surreptitiously add or change existing package, and replace someone else's key with your own, say. So let's run through that again: having a `dinstall' key used to automatically sign Packages.gz: * doesn't solve the insoluble * plugs the main vulnerability * is relatively easy to setup and maintain * is easy to fix, should it be exploited Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. Note that this makes debian-keyring a more or less standard package. Either that, or just let dpkg Recommend it. If it is not installed, package verification is not available. Let me rephrase that. This makes debian-keyring a base package, since if you want to verify the packages you download, you really want to do it right from the word go, rather than just some time later. This isn't necessarily a bad thing, but it's worth noting since it adds about half a floppy to base. Note that it requires you to trust everyone in that keyring with every aspect of your system. That's already the case, isn't it? Signed packages give you the benefit, that you'll *only* have to trust the maintainers you install packages from - not every man-in-the-middle. It's currently the case, yes, but it *could* be changed. You could, for example setup dinstall so that it wouldn't accept NMUs of certain important packages (such as gnupg). Note that this doesn't help with revoking signatures: if some idiot decides that being a Debian maintainer should give him the right to 0wn all the machines that use his package; then gets thrown out; he can still use his key to sign packages that'll be happily installed by anyone with an out of date debian-keyring. Indeed. But I am sure that this fact will get big coverage on the lists and the websites. And, equally, a deliberately compromised package would probably get a fair bit of coverage too. It'd be nice not have to rely on staying up to date with slashdot and the mailing lists and IRC before doing an apt-get dist-upgrade though. Debian has handled security leaks in other packages well - this is just a leak in the package system that updating debian-keyring will plug, nothing else. The *reason* Debian handles security bugs (security leaks?) in packages well is that we have a mechanism for handling bugs, and we make use of it. The best way to ensure that we always have mechanisms for fixing things is to think about it first, not just handwave it away and say She'll be right, mate. If he can gain control of an ftp mirror, he can keep updating the debian-keyring.deb to include his key, and keep maintaining any packages he likes. No, see below. ...where you add extra complexity to the security model. The originally stated model does have this problem. It also leads to something of a chicken-and-egg situation. It's much easier to verify a *single* key than that every one of five-hundred of the things is uncompromised. (It can be signed by previous versions of itself, it can be widely published in Debian books, it can be signed by the ftp team, etc) The solution is to have one master key (in the hands of a highly trusted person) The phrase is A solution. The highly trusted person you're referring to here is eash member of the new-maintainer team, by the way. that is treated like your single key (published everywhere). Every developer's key has to be signed by at least by this key. And if a developer gets kicked out? You can't revoke a signature (PGP signatures are designed to certify identity, not trustworthyness), so instead you have to revoke the key, and sign everyone else again. Revoke n people, and you have n signatures on every key in the keyring. How elegant. And note that this makes revocation a standard (although
Re: Signing Packages.gz
On Mon, Mar 27, 2000 at 01:42:47AM +0200, Robert Bihlmeyer wrote: There is no need to check all of [the packages] Well, it'd be nice to be able to do so, to verify that a mirror hasn't been compromised, but no, you're right. Actually, now I think about it, the Packages file itself is valuable information. Consider a Packages file that doesn't actually changes the .deb's, but changes the netbase entry, say to read: Package: netbase Depends: vim Conflicts: nvi, emacsen and leaves everything else the same. You can only achieve fairly petty vadalism with this, but it would still be nice to avoid it, IMO. One thing to consider is that this would make the Package.gz file noticeably bigger. Per-package signatures would naturally accompany the package, not the Packages.gz file. Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. This key's security value would not be much above that of the debian machines themselves. Speaking about `more secure than the debian machines themselves' is meaningless. If you can compromise the debian machines themselves, you're home and hosed. You can do anything and everything. And it's a *major* *major* change to the way we do *everything* to try to change that, really. We may *do* everything in a decentralised, distributed manner, but we're *still* one organisation. If you can take over `Debian', by definition you've taken over Debian. You'd get about the same security by a mirror of master, that is administed by the same people (does this mirror exist?). No, it doesn't. And what would such a mirror actually *do*? Just mirror master as it gets compromised, and end up compromised itself? Or should there be three masters which talk to each other and vote on any changes? (And then, somehow, you need to work out how to avoid people compromising all three machines in just one heck, by, say, breaking into one of the personal machines of anyone with root access on all three...) Whose key should be used by entry-level signing? I assume that .debs are created by an automated process with no user intervention. Huh? .debs are never created and uploaded without any intervention, as I understand it. Including ports. They're moved from Incoming to unstable without interaction, but that's about it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgp244VJQnc89.pgp Description: PGP signature
Re: Signing Packages.gz
On Sat, Mar 25, 2000 at 11:03:11PM +0100, Robert Bihlmeyer wrote: Chris Frey [EMAIL PROTECTED] writes: So my question is, what are your thoughts on adding a signature to the current Packages.gz file, or adding a similar *dsc file for it, which is then signed? Do you want to sign each package entry, or the whole file? Whose signature would be used? I think each Packages file should be signed. And the person responsible for generating those Packages files should be the one to sign it, no? (BTW, You could add Mail-Copies-To: poster to the headers you use for this list.) Cool, thanks. - Chris -- --- Chase the dream, not the competition. - motto of the Nemesis Air Racing Team
Re: Signing Packages.gz
On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: The whole file --- verifying each entry would take at least three minutes on my hardware, and god knows how long on anything moderately old or outdated. I certainly wouldn't want to try it on m68k on a regular basis, eg. (If doing something just once takes a second; doing it 4000 times takes a bit over an hour) I don't think it is useful to sign the Packages file, because: Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). There doesn't really seem a huge amount of choice here, to me. Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. There was some discussion about this in the past. The trick is that security should be implemented in dpkg(-dev), not somewhere else. This has the advantage that it works also with individual packages you don't get from an archive source. It cuold also be used to verify the origin of the package. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server Marcus Brinkmann GNUhttp://www.gnu.orgfor public PGP Key [EMAIL PROTECTED], [EMAIL PROTECTED]PGP Key ID 36E7CD09 http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ [EMAIL PROTECTED]
Re: Signing Packages.gz
On Sun, Mar 26, 2000 at 04:02:20PM +0200, Marcus Brinkmann wrote: On Sun, Mar 26, 2000 at 09:00:34AM +1000, Anthony Towns wrote: The whole file --- verifying each entry would take at least three minutes on my hardware, and god knows how long on anything moderately old or outdated. I certainly wouldn't want to try it on m68k on a regular basis, eg. (If doing something just once takes a second; doing it 4000 times takes a bit over an hour) I don't think it is useful to sign the Packages file, because: A signature authenticates the source of a document. That's worthwhile, since verifying the source of a Packages file lets you transitively verify the source of all the packages in a distribution. Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. Any such key would have to be considered insecure, no matter how soon you revoke it. So the paranoid people still don't trust it, and the other don't care (probably). Nonsense. The only reason not to trust a key dinstall uses explicitly for signing Packages is if you believe dinstall is compromised. If you believe that, then you shouldn't be downloading .deb's *ever*, because you're immediately running *untrusted* scripts as root on your systems. If dinstall *isn't* compromised, it's still possible that your favourite FTP site is, in which case all they need to do to compromise your machine is replace a .deb with their own hacked version and let you download it. Automatically signing things is less secure than manually signing things, and you need to do some extra stuff to not have gaping security holes when automatically signing things, but sometimes there isn't that much of a choice. All this FUD about no, no, we can't do that, it's not secure! is, well, just that. *Nothing* is absolutely `secure', some things just have fewer or different exploits than others. There doesn't really seem a huge amount of choice here, to me. Packages should come with their *.changes file, and dpkg should have an option to verify the signature of individual packages. There was some discussion about this in the past. The trick is that security should be implemented in dpkg(-dev), not somewhere else. This has the advantage that it works also with individual packages you don't get from an archive source. It cuold also be used to verify the origin of the package. Note that this makes debian-keyring a more or less standard package. Note that it requires you to trust everyone in that keyring with every aspect of your system. Note that this doesn't help with revoking signatures: if some idiot decides that being a Debian maintainer should give him the right to 0wn all the machines that use his package; then gets thrown out; he can still use his key to sign packages that'll be happily installed by anyone with an out of date debian-keyring. If he can gain control of an ftp mirror, he can keep updating the debian-keyring.deb to include his key, and keep maintaining any packages he likes. With a dinstall key, the only way he can do this is if he's a member of the ftp team or debian-admin. It also leads to something of a chicken-and-egg situation. It's much easier to verify a *single* key than that every one of five-hundred of the things is uncompromised. (It can be signed by previous versions of itself, it can be widely published in Debian books, it can be signed by the ftp team, etc) Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgpLmXIPb5ukR.pgp Description: PGP signature
Re: Signing Packages.gz
Anthony Towns aj@azure.humbug.org.au writes: On Sat, Mar 25, 2000 at 11:03:11PM +0100, Robert Bihlmeyer wrote: Do you want to sign each package entry, or the whole file? The whole file --- verifying each entry would take at least three minutes on my hardware, and god knows how long on anything moderately old or outdated. Verifying /one/ entry takes three minutes? On my 486 box (which I'd call moderately outdated) verifying a 1024 bit DSS signature with GPG takes under two seconds. (Or did you mean verifying all entries? See below!) I certainly wouldn't want to try it on m68k on a regular basis, eg. (If doing something just once takes a second; doing it 4000 times takes a bit over an hour) There is no need to check all of them - only those for packages that are about to get installed. For reference: on said 80486 apt-get install gnupg took over two minutes (without downloading). Adding two seconds to that would be no problem, IMHO. One thing to consider is that this would make the Package.gz file noticeably bigger. Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. This key's security value would not be much above that of the debian machines themselves. You'd get about the same security by a mirror of master, that is administed by the same people (does this mirror exist?). Whose key should be used by entry-level signing? I assume that .debs are created by an automated process with no user intervention. -- Robbe
Re: Signing Packages.gz
Chris Frey [EMAIL PROTECTED] writes: So my question is, what are your thoughts on adding a signature to the current Packages.gz file, or adding a similar *dsc file for it, which is then signed? Do you want to sign each package entry, or the whole file? Whose signature would be used? Thanks. Please CC me on replies, since I'm not on the list. (BTW, You could add Mail-Copies-To: poster to the headers you use for this list.) -- Robbe
Re: Signing Packages.gz
On Sat, Mar 25, 2000 at 11:03:11PM +0100, Robert Bihlmeyer wrote: Chris Frey [EMAIL PROTECTED] writes: So my question is, what are your thoughts on adding a signature to the current Packages.gz file, or adding a similar *dsc file for it, which is then signed? Do you want to sign each package entry, or the whole file? Whose signature would be used? The whole file --- verifying each entry would take at least three minutes on my hardware, and god knows how long on anything moderately old or outdated. I certainly wouldn't want to try it on m68k on a regular basis, eg. (If doing something just once takes a second; doing it 4000 times takes a bit over an hour) Whose key should be used? Probably a special one just for dinstall, that's kept fairly securely by the Novare and -admin folks, and revoked regularly. There doesn't really seem a huge amount of choice here, to me. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] 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 pgplbf3OFr3O5.pgp Description: PGP signature
