Bug#760102: gnupg 2.0.27 in debian unstable, with some fixes that we might want to consider for jessie

[Daniel Kahn Gillmor]

On Thu 2015-05-28 10:35:28 -0400, Josselin Mouette wrote:
> Yes, this is what I was worried about. Thanks for your explanations.
> Sorry for jumping in too fast with the “RC bug” wording, which was not
> mandated given what you have in mind - I guess the breakage in unstable
> did make me nervous.

What breakage are you seeing in unstable?  the 2.1.x series is still
only in experimental, so --use-standard-socket isn't happening in
unstable... yet ;)

> I’m not really sure your solution is worth deploying to jessie this way,
> though. Maybe a few words in the release notes would be enough.

What words would you suggest?  Maybe something like this:

    If you run a headless system, we recommend that you install
    pinentry-curses before upgrading to jessie.  This will satisfy
    gpg-agent's pinentry dependencies, and will avoid pulling in
    graphical libraries and toolkits on upgrade.

    If you run GNOME and use GnuPG with smartcards, S/MIME, or want
    stronger security protection for your GnuPG secret material, you may
    want to disable GNOME keyring's gpg-agent interface.  You can do
    this by modifying files in /etc/xdg/autostart.  See
    /usr/share/doc/gnome-keyring/README.Debian for more information.



But this all really sounds like something we're supposed to have taken
care of as a distro.  For example, by making sure that packages like
GnuPG by default pull in only minimal dependencies; and ensuring that
graphical environments (desktop tasks) recommend the use of a matching
pinentry for those users who use GnuPG and already have all the
graphical toolkits installed; and making sure that gnome-keyring doesn't
degrade the functionality or security of other software like GnuPG.

These are the kind of system integraton tasks that a distro should be
taking care of, and we (myself included) have been failing at it in this
case.  Users shouldn't have to read paragraphs like the proposed text
above, their tools should Just Work :/

> If gnome-keyring upstream agrees (I don’t know why they wouldn’t, but I
> haven’t looked at the architecture in detail), it looks like the
> long-term solution. But so far it isn’t there. It would be much
> appreciated if you could at least revert the --use-standard-socket
> change until this new pinentry has been uploaded to unstable and
> properly integrated in reverse dependencies wherever needed. 

I've prodded upstream about making a pinentry release including
pinentry-gnome3.  Hopefully it'll happen in the next few days, and then
i'll send it through NEW.

I don't think reverting the --use-standard-socket change is going to
happen, that's a rather far-reaching change and upstream is pretty
committed to it -- it provides a nice simplification for all code
running in the common (non-remote-$HOME) case.

You mention "breaking remote $HOME" -- that's the main concern i had
with the change as well, but maybe we should open that as a separate bug
report, specify exactly what the scope of the breakage is, and try to
find some solutions for it that are palatable to upstream.

Regards,

     --dkg