Re: Future security problem (was Re: be careful with Replaces, please)
Christian Schwarz wrote:
>
> I suggest that we add a new control field to our packages called
> "Origin:" (or similar). This could either be set to "SPI" or
> "Debian", for example. Then, all Debian packages should be signed
> with some PGP key (either only one key for the whole system or by
> the maintainer's key).
>
> dpkg could have its own keyring. Whenever dpkg installs a package, it
> checks the key against its keyring. If the key is not found in the
> keyring, dpkg stops installing (this can be overriden by some --force
> option).
>
> The default keyring would probably be the developers keyring.
> The sysadmin could then add new keys of persons/organziations which
> he/she trusts to that keyring.
>
> Comments?
Just to repeat what we already said on a different list, with the actual
scheme we have m packages signed by n developer's keys, but only one
sign per package.
On average, the number of keys to be revoked each year depends on the
number of developers. Considering that users are installing from CD that
are usually 3/4 months old (but this time we have a 6 month delay), so
you can see how one developer key, which is privately handled by the
developer, can be kept active as a trusted key because of all the
packages signed with that key that are on all the CDs, even if the
developer has leaved the project, maybe after a nasty flame (you see how
this could easyly happen). He can maybe start signing his own packages
with the same key he used on debian, and putting them on sunsite.
Developers keys should be used only to make sure that the upload came
from the developer in that very moment of the upload itself.
To trust packages on a CD we need a scheme that woudn't be seriously
affected by "normal" accidents in the life of the distribution.
I proposed that a number of "highly trusted" people (senior developers,
for example) create a certain number of _new_ keys that they will use
(one per person) only to create detached certificates to distribute
close to the packages. Three to five certificates per package would be
enough. (detached because this way the certificates can be done in
parallel, on different machines, and _not_ on some public host.)
Then dpkg must check all the certificates of each package that it
installs, and accept only those who have some level of trust (for
example at least 3 out of five, or two out of three) maybe displaying
warnings for different levels of trust (all user definible).
Users then should be able to add keys from other people, but the keyring
we supply should also contain some sort or keys-to-be-rejected, so we
can add to that list the keys that we discover have been used to build
trojan horses or such things.
With this scheme the need to urgently revoke one key would have low
possibility to happen, as dpkg could trust packages even when one key is
compromised, because the possibility that _all_ keys from different
_expert_ people (wo is more likely to follow all the rules for correct
handling of private keys) would be compromised at the same time is quite
close to zero.
Fabrizio
--
| fpolacco@icenet.fi fpolacco@debian.org fpolacco@pluto.linux.it
| Pluto Leader - Debian Developer & Happy Debian 1.3.1 User - vi-holic
| 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E
> Just because Red Hat do it doesn't mean it's a good idea. [Ian J.]
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: