Bug#620064: apt: please drop dependency on gnupg

[Carsten Hey <carsten@debian.org>]

* David Kalnischkies [2011-03-29 20:03 +0200]:
> On Tue, Mar 29, 2011 at 18:32, Carsten Hey <carsten@debian.org> wrote:
> > please drop apt's dependency on gnupg.
> >
> > There has already been some discussion in related bugs #387688 and
> > #558784.

I suggest a possible plan to get rid of the gnupg dependency without
breaking things below, without reading yours before and then compare
both:

1.  apt and d-a-k both depend on gnupg in a stable release.

    done

2a. apt does support a new way to handle keys.

    done, even in Squeeze if I understood your mail correctly?

2b. d-a-k drops the dependency on gnupg and still uses apt-key in its
    maintainer scripts

    not done

2c.  d-a-k uses the new way to handle keys and uses appropriate package
    relationship fields to ensure a sufficient new apt version is
    installed, e.g. "Breaks:".  If 2a is done in Squeeze, adding this
    package relationship field can be skipped.

    not done

3.  apt replaces the gnupg dependency with a dependency on gpgv and uses
    a versioned dependency on d-a-k.

    not done


2a, 2b and 2c can be done independently from each other.


> How do we move forward if d-a-k as well as APT do not depend on gnupg
> anymore while d-a-k in its current state needs it to add its keys to
> the trusted.gpg file through apt-key?

I hope my suggestion above addresses your question, if it does not
please drop me a mail.


> For me a plan looks more like:
> - switch all keyring packages to store their keyrings in the new (=squeeze
>   supports it) trusted.gpg.d directory - at best even more fragments if it
>   makes sense, e.g. oldstable keys in an other file than the one for testing.
>   Links are fine, too.

This is 2a and 2c from my list above.

As long as the old interface is not removed and the other keyring
packages depend on gnupg, there is no need to touch them now.  Switching
them can be done later.  Prerequisite for this is that apt-key fails in
a sane way if gnupg is not installed.

> - all keyrings recommend gpgv as thats enough for APT to check the signature,
>   or depend on gpgv - depends on (pun intended) if you want to be able to use
>   the keyring without APT or not…

This is 2b, though a bit different.

I see no benefit in letting keyring packages recommend or depend on
gpgv.  Keyrings are just data and data can also be mailed or put on
a webserver.

> - remove the gnupg dependency from APT

This is 3, also a bit different.

> (- remove the apt dependency from all keyring packages)

I don't think there is one.

> (- downgrade APTs d-a-k dependency to a recommend)

If you want to make d-a-k and gpgv optional, I would let apt recommend
both.  In this case, ensuring that debootstrap and cdebootstrap install
both in their minimal variants might be useful (people could still
remove these packages).

I have no opinion whether d-a-k and gpgv should be optional or not.

> - close all three bugs mentioned in this bugreport here

The d-a-k one can be closed immediately if its maintainers do the
upload.  Alternatively, you might want to extend (retitle and describe
what apt needs) it to also include adaption of d-a-k to the new apt
interface.  Or you just file a new bug about this if you prefer it this
way.

Without knowing the details, I guess #558784 can be closed after all
keyring packages have switched to the new interface and the old one has
been disabled in apt.  On the other hand, carrying the old interface
a while in Debian might be useful for third party keyring packages.
Then #558784 could be closed after all keyring packages in Debian have
switched with the rationale that only unsupported third party packages
using deprecated interfaces trigger it.  But as already said, I don't
know the details of this bug.


In sum, both plans are very similar :)


> I tried to convert the debian-archive-keyring recently, but failed at the
> attempt to split the keyring into different files - but yeah, ultimately,
> you (as in debian) shouldn't trust a patch from someone without an official
> status like me anyway in such a security sensitive context, so feel free to
> make it happen yourself: i would be happy about it at least (beside that I
> have done the split on my local machine by hand for testing proposes anyway).

NMUing a package from the release team doesn't seem to be the best thing
to do, so there is no difference if I send a patch to them, you do, or
Stefan Mappus, who will have some spare time to waste soon, does ;)


Regards
Carsten