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 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: