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
> > 1 2
> >
> > 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
> 1 users
> | ^
> `--------->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 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.
Only for individual packages. In the signed packages case, you have to trust
everyone and their dog, *and* the security of master, *and* the admin team
etc.
This is exactly what I find irritating. You are trying to convince me that
my proposal is flawed because you need to trust anyone. But it is exactly
this false sense of security in your model, that one might believe he only
needs to trust the admin team or dinstall. There are still all developers
who uploaded the packages.
In my model, you actually need to trust *less* things.
The only way to look at it where you get more keys to trust is the
out-of-date keyring issue. But those are seperate things. I have to be
careful manually when upgrading the keyring. The rest can then be automated,
just as dinstall is.
So, even in my model there is only one key you really have to trust, and
this is the debian-keyring. The trust for all other packages in the archive
propagates.
> > 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.
Yes. I don't know how one can come to the conclusion that this is
acceptable, though. Especially if there is a better solution, that is not
much harder to implement.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server
Marcus Brinkmann GNU http://www.gnu.org for public PGP Key
Marcus.Brinkmann@ruhr-uni-bochum.de, marcus@gnu.org PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ brinkmd@debian.org
Reply to: