[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <robbe@orcus.priv.at>
sig!       36FF3F58 1999-07-24  Robert Bihlmeyer (Testkey - do not use)
sig!       E6583EFB 2000-03-31  Robert Bihlmeyer <robbe@orcus.priv.at>

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.

-- 
Robbe


Reply to: