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

Re: ITP: debian-backports-keyring -- GnuPG archive key of the backports.org repository



Patrick Schoenfeld <schoenfeld@in-medias-res.com> writes:

> Hi Neil,
>
> On Sun, Jun 22, 2008 at 09:54:43PM +0100, Neil Williams wrote:
>> > Do you mean from a central repository, somewhat like a keyserver? :-)
>> > How would one check integrity then?
>> 
>> Precisely as you do with any key - signatures and gpg integrity checks
>> when the key is imported into apt-key.
>
> well I understood the proposal to do it automatically so it wouldn't
> happen like I handle it currently. Now I have the possibility to
> explicit allow and deny certain keys in my setup. I can do this by
> checking mostly objective standpoints but also because I don't like the
> nose of the one providing the repository, so to say.
>
> Thats an important point, because technical aspects cannot decide
> weither you trust someone or not (except for the trust level on the key)
> So the key would needed to be signed by someone who *I* actually trust.
>
> Regards,
> Patrick

For example: Each repository puts its keyring into Release.keyring
(next to Release and Release.gpg). The Release.keyring could be listed
with checksum in Release so frontends know it is there and when it
changes.

apt-get/aptitude update would automatically fetch Release.keyring into
/var/cache/apt/archives/partial/, pick out all changed keys and verify
their signatures with the existing apt keyring and possibly some
/usr/share/keyrings/*.

Depending on what signatures are found I could envision the following
next:

- Key rollover: changes can be verified with apts own keyring (new key
  is signed by old key). Accept key without interaction. A simple
  notice should do fine.

- Rollover failure but role-key verifiable: changes can not be
  verified by apts own keyring but by *-role-keys.gpg. Display the
  signatures and go interactive. Default should be to accept the key.

- No or loose verification: neither apts nor the *-role-keys.gpg keyrings
  can verify the change. Display the signatures indicating where
  e.g. debian-keyring.gpg can verify one and go interactive. Default
  should be NOT to accept the key. Users should really verify the key
  manually.


I'm not proposing that just any key should be silently accepted. Just
that it should be automatically fetched and independent of debs. I
already did run into a case where I could not update the keyring
package because the Release signature required the new keyring
package.

MfG
        Goswin


Reply to: