Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Pierre Ynard]

> Do you really think it's a violation of debian policy that gpgme
> explicitly Depends on the full gnupg suite?

I'm not sure, I suppose policy arbitration is a bit outside of my
skills. I think what's going on goes against the policy, and the current
state prevents any flexibility to handle the situation differently
through other means, such as package manager preferences or dependency
on higher level applications. I mentioned a few access libraries
above, I imagine for example libpulse0 on its own provides even less
functionality than libgpgme11 - that is, it allows binaries dynamically
linked against its shared object to load, and that's about it - yet
it merely has a Suggests: pulseaudio. It seems to me that quite a few
access libraries that are depended on due to dynamic link, work on that
same model.

> Would the following change satisfy your concerns?

Yes.

> Would you be willing to look out for (and help respond to) any bug
> reports that debian receives about users of gpgme (including, but not
> limited to, mutt users) who can no longer use their secret keys as
> expected?

No, and anyway I really don't have the expertise for it.

Is there any upgrade path that could unwittingly leave a user in this
situation? I don't think there was any "gpg" package before in a
release? Perhaps it would be better to put gnupg in Recommends too, is
that possible?

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Werner Koch]

On Wed, 29 Nov 2017 23:56, d...@fifthhorseman.net said:

> libgpgme provides *no functionality* whatsoever if gpg is not installed.

That is not fully correct.  For example in the Outlook plugin we used to
use gpgme just to provide data objects with callback functionality and
to connect to the so-called UI-server.

It is also possible to use GPGME to connect to arbitrary Assuan servers,
however except form the UI-Server (i.e. gpa --daemon) there are not may
other Assuan servers outside of the GnuPG realm.

The general idea about GPGME is an API for end-to-end encryption.  It
_might_ be that GPGME tests immediately for GnuPG availibility but that
seems to be wrong.  This should be delayed until the caller really
requests an GPGME context for the OpenPGP or SMIME protocol.

OTOH, given that there are many signed mails, Mutt will in any case try
to verify those mails and thus run into a GPGME error.  The erro
handling should be more gracefully then.  Unfortunately since the last
15 years or so I use Mutt only rarely.

I can't say anything about Debian packing rules, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpUeelRZiZv3.pgp
Description: PGP signature

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Daniel Kahn Gillmor]

Hi Pierre--

Thanks for continuing to engage constructively on this.

The GnuPG packaging split that happened in 2.1.21-4 (and the subsequent
packages added to support things like WKS) does indeed cause more things
to be pulled in by the explicit dependency on the "gnupg" package than
used to be the case.

On Wed 2017-11-29 21:48:01 +0100, Pierre Ynard wrote:
> how about the reason that it violates the Debian policy?? I've brought
> it up several times in this thread already, and nobody has denied it.

iiuc, your contention about debian policy is:

>> The policy states that hard dependencies are for when they're needed
>> to provide a significant amount of functionality. mutt provides
>> plenty of functionality already without the option to GPG-sign emails
>> and even without checking email signatures. So from that point of
>> view, it hardly seems appropriate that mutt pulls unconditionally the
>> whole GnuPG suite.

But please consider that policy governs immediate dependencies.  That
is, it's not abouve whether *mutt* provides significant functionality
without GnuPG.  It's about whether *libgpgme* provides significant
functionality.

libgpgme provides *no functionality* whatsoever if gpg is not installed.

Without gpg-agent or dirmngr, libgpgme cannot provide secret key
operations, which is clearly a "significant amount of functionality".

Do you really think it's a violation of debian policy that gpgme
explicitly Depends on the full gnupg suite?

> Regardless, once again, I've made several suggestions that would leave
> them installed by default like you mentioned. Nobody has denied that it
> would be a positive solution for everybody.

Would the following change satisfy your concerns?  Would you be willing
to look out for (and help respond to) any bug reports that debian
receives about users of gpgme (including, but not limited to, mutt
users) who can no longer use their secret keys as expected?


diff --git a/debian/control b/debian/control
index f99a7401..429d2d9e 100644
--- a/debian/control
+++ b/debian/control
@@ -55,17 +55,20 @@ Description: GPGME - GnuPG Made Easy (development files)
 Package: libgpgme11
 Architecture: any
 Multi-Arch: same
 Pre-Depends:
  ${misc:Pre-Depends},
 Depends:
- gnupg (>> 2) | gnupg2 (>> 2.0.4),
+ gnupg (>= 2.1.21-4) | gpg,
  ${misc:Depends},
  ${shlibs:Depends},
-Suggests:
- gpgsm (>> 1.9.6),
+Recommends:
+ dirmngr,
+ gpg-agent,
+ gpg-wks-client,
+ gpgsm,
 Description: GPGME - GnuPG Made Easy (library)
  GPGME is a wrapper library which provides a C API to access some of the
  GnuPG functions, such as encrypt, decrypt, sign, verify, ...
  .
  This package contains the library.
  
Note that this will make backporting of libgpgme to older distributions
more difficult.

Regards,

--dkg


signature.asc
Description: PGP signature

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Pierre Ynard]

> Perhaps we need to consider shipping the same software (the full GnuPG
> suite) in a single, monolithic package.  That way, there won't be any
> "new packages" for people to be upset about.
> 
> The current package split is designed to try to accomodate people who
> really want a minimalist installation.  However, it appears that it is
> antagonizing those same people, so it might not be worth maintaining.
> Would you be happier if there were fewer binary packages?

I understand your efforts to offer flexibility, and the challenges
to get it to work right and the maintenance burden implied - and I
appreciate your looking into this.

However that sounds like a rather unfriendly proposition, especially
at this point. It essentially sounds like the same bloat would still
be there, except less visible, except people would just never know
about it, and so couldn't be upset about it. Also way to go solving
the problem of uninstallable packages by removing the option of having
separate packages to begin with... I was complaining about a lack of
freedom to choose what I don't want to install, and you make me an offer
for even less freedom and choice.

What antagonizes me is when I read in the changelog things that are for
my use case bloat creep. It only mildly antagonize me an upgrade prompts
for new extra packages; what really antagonize me is then when I look
into it and see no option out of it because of the dependency creep
hell.

> reasonable mail user agents are doing exactly that. Please see
> https://autocrypt.org/ for more discussion of this approach. If you
> would like to encourage the Mutt developers to consider the Autocrypt,
> that would be great!

What do you want me to reply... that I'm sorry for using an unreasonable
MUA, mutt, which must be making me out of touch from what encryption
should be?...

> As for "new services", there are *no* new services started by any of
> these packages on a standard debian system if the functionality is
> not requested. There are sockets opened by the user's systemd session
> manager, but the services themselves do not run unless someone tries
> to access them. If they try to access them, then presumably that
> implies that they want them installed, no?

No; that view is not very conservative. It could be a mistake or
something inadvertent from the user; an exploit attempt; a bug or a
corner case, a test gone wrong; or something enabled by the maintainer
or packager who decided it was best for the average user, that the
system administrator doesn't agree with.

> The fact is, libgpgme explicitly fails in many use cases if gpg-agent
> or dirmngr are not available. This partial, unpredictable failure is
> not acceptable for a library package.

I don't see how. That's normal error handling, and the very reason
for error handling. Every time I start vlc, the pulseaudio audio
output plugin is probed, and libpulse0 throws a failure because it
can't connect to the PulseAudio server, which is not installed on my
system. By that logic it would be unacceptable for libpulse0 to be
installed without the full pulseaudio, unacceptable for libsystemd0 to
be installed without a systemd init, unacceptable for libudev0 to be
installed without udev... Oh the tyranny of pervasive access libraries,
imagine that.

> I see no reason to inflict this on users by default, which is what is
> likely to happen for anything using gpgme on debian if the library
> package does not explicitly depend on the full suite.

Besides my above comparison, how about the reason that it violates the
Debian policy?? I've brought it up several times in this thread already,
and nobody has denied it. Does nobody care about honoring the policy on
dependencies? You're making me depressed, it's like you're not listening
to me.

Regardless, once again, I've made several suggestions that would leave
them installed by default like you mentioned. Nobody has denied that it
would be a positive solution for everybody.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Daniel Kahn Gillmor]

On Tue 2017-11-28 09:22:48 +0100, Werner Koch wrote:
> On Tue, 28 Nov 2017 00:49, d...@fifthhorseman.net said:
>
>> The fact is, libgpgme explicitly fails in many use cases if gpg-agent or
>> dirmngr are not available.  This partial, unpredictable failure is not
>
> It should return an error like No Agent, No Dirmngr, or No Pinentry.  If
> not that is a bug either in GnuPG or gpgme.

indeed, this is the "explicit failure" that i am talking about.

I see no reason to inflict this on users by default, which is what is
likely to happen for anything using gpgme on debian if the library
package does not explicitly depend on the full suite.

--dkg

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Werner Koch]

On Tue, 28 Nov 2017 00:49, d...@fifthhorseman.net said:

> The fact is, libgpgme explicitly fails in many use cases if gpg-agent or
> dirmngr are not available.  This partial, unpredictable failure is not

It should return an error like No Agent, No Dirmngr, or No Pinentry.  If
not that is a bug either in GnuPG or gpgme.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpeF6l9Kqh3L.pgp
Description: PGP signature

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Daniel Kahn Gillmor]

On Mon 2017-11-27 13:54:06 +0100, Pierre Ynard wrote:
> I understand your point, and your drive for security is great. However
> to foster the use of free software we should get away from forcing users
> to install unwanted software. Due to the current circumstances, I refuse
> to proceed to any gnupg upgrade that would force on me all these new
> packages and services that I don't need. How does that make you feel?

Perhaps we need to consider shipping the same software (the full GnuPG
suite) in a single, monolithic package.  That way, there won't be any
"new packages" for people to be upset about.

The current package split is designed to try to accomodate people who
really want a minimalist installation.  However, it appears that it is
antagonizing those same people, so it might not be worth maintaining.
Would you be happier if there were fewer binary packages?

As for "new services", there are *no* new services started by any of
these packages on a standard debian system if the functionality is not
requested.  There are sockets opened by the user's systemd session
manager, but the services themselves do not run unless someone tries to
access them.  If they try to access them, then presumably that implies
that they want them installed, no?

The fact is, libgpgme explicitly fails in many use cases if gpg-agent or
dirmngr are not available.  This partial, unpredictable failure is not
acceptable for a library package.

> Regarding what I said about the manual setup step: if you want to foster
> and implement the core role of encryption in email, then I would suggest
> to go all the way with an out-of-the-box experience and set up automatic
> private key creation on package configuration or first launch;

reasonable mail user agents are doing exactly that.  Please see
https://autocrypt.org/ for more discussion of this approach.

If you would like to encourage the Mutt developers to consider
the Autocrypt, that would be great!

Regards,

  --dkg


signature.asc
Description: PGP signature

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Pierre Ynard]

Hello,

> > Many mutt users do not do any secret key operation. I think those
> > who do need to create or setup a private key first - and probably
>
> To foster the use of end to end encryption we should get away from the
> need to install plugins. Encryption should be a core functionality of
> all MUAs and not something optional.

I understand your point, and your drive for security is great. However
to foster the use of free software we should get away from forcing users
to install unwanted software. Due to the current circumstances, I refuse
to proceed to any gnupg upgrade that would force on me all these new
packages and services that I don't need. How does that make you feel?

Saying that "to foster X, we should have Y installed by default" is not
a sufficient argument on its own because that can be said for about
anything. And regardless, that's not what the Debian policy says about
package dependencies. I'm not going to argue with your opinion about
what GnuPG's place in email should become; because that's not the
criterion for hard dependencies. If this was about web browsers, you
could rightly point out that without HTTPS support, much of the web and
most mainstream websites would be inaccessible, severely questioning the
usability of the browser without it. However for email, this is just not
the case at all.

Regarding what I said about the manual setup step: if you want to foster
and implement the core role of encryption in email, then I would suggest
to go all the way with an out-of-the-box experience and set up automatic
private key creation on package configuration or first launch; because
without that, the dependencies that were pulled in effectively remain
dead code - which proves that they aren't really dependencies, and
leaves them as unused bloat.

You will note that I am not even at odds with you on the default
availability of these tools: I made several suggestions such as
"Recommends: gnupg" or "Depends: gnupg | gpg" that would still have
them installed and fully available; it would just honor the policy and
restore the freedom to uninstall them to users who don't want or need
them.

Best regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#872368: [pkg-gnupg-maint] Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Werner Koch]

On Thu, 23 Nov 2017 13:48, linkfa...@yahoo.fr said:

> Many mutt users do not do any secret key operation. I think those who
> do need to create or setup a private key first - and probably put some

To foster the use of end to end encryption we should get away from the
need to install plugins.  Encryption should be a core functionality of
all MUAs and not something optional.

For Mutt pinentry-curses should be installed first so that the default
pinentry-gtk won't suck in all kind of unneeded X stuff.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpu82wdAcaC0.pgp
Description: PGP signature

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Pierre Ynard]

Dear maintainer,

I find myself with the same request as the original reporter; I will try
to answer your questions for myself.

> So let me ask you more about your motivation with this bug report
> here -- are you interested in having fewer packages installed? less
> software total? smaller disk images? something else?

I'm interested in less bloat, fewer packages, less software, less
administration burden, and also in particular no useless services
running whereas I'm never going to use them. Less is more. I'm also
interested in my freedom of choice not to install software, which I
just prefer not to install, for whatever personal reason that is; I
understand in general that you provide in your packaging good and
educated decisions and defaults, but I never take kindly to one that I
get stuck with with no way out.

The policy states that hard dependencies are for when they're needed to
provide a significant amount of functionality. mutt provides plenty of
functionality already without the option to GPG-sign emails and even
without checking email signatures. So from that point of view, it hardly
seems appropriate that mutt pulls unconditionally the whole GnuPG suite.

I understand if you think it's best to avoid setups with missing pieces.
To prevent this from happening unless it's really the user's choice, may
I suggest to introduce the dependency as a Recommends field, or even
something like a "Depends: gnupg | gpg" ?

Many mutt users do not do any secret key operation. I think those who
do need to create or setup a private key first - and probably put some
thinking into where and how to secure it - so extra manual setup is
required anyway. I would also suggest that this could be the step where
interested users would opt in to install the extra packages they need.

I hope this tells you more on what you were asking about, and that this
issue can move forward.

Regards,

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[Daniel Kahn Gillmor]

Hi RjY--

On Fri 2017-08-18 13:51:29 +0100, RjY wrote:
> As a test I created an empty package to subvert the dependency and see
> if anything breaks. The control file was thus:
>
> Package: no-full-gnupg-install
> Maintainer: RjY 
> Architecture: all
> Version: 1
> Depends: gpg (>= 2.1.23-2)
> Recommends: gpg-agent (>= 2.1.23-2)
> Provides: gnupg (= 2.1.23-2)
> Description: No full GNUPG install
>  This package "provides" gnupg, to avoid libgpgme11
>  pulling in the full gnupg suite, until 872368 is fixed.
>
> This allowed installing only gpg and gpg-agent. So far, things still
> seem to be working as expected: mutt appears fine, I can still use gpg
> to encrypt/decrypt backups, and so on. It would still be good to get
> this fixed in src:gpgme, though!

This is a neat suggestion, but i'm not convinced it's a good idea.

In particular, if you don't have gpg-agent, you won't be able to do any
secret key operations.  if you don't have dirmngr, network access will
fail.

gpgme aims to support all of those things.  I *really* don't like the
idea of introducing those kinds of hard-to-debug failures.  Furthermore,
GnuPG upstream prefers that we *don't* ship a bunch of separate
packages, they see the whole thing as a suite.

So let me ask you more about your motivation with this bug report here
-- are you interested in having fewer packages installed?  less software
total?  smaller disk images?  something else?

The other package re-arrangement i've been flirting with on the gnupg2
source package is to go ahead and collapse *all* of the files shipped in
the binary packages together (with the exception of gpgv, which needs to
be separate and small for validation-only systems).  That would make a
single package, so there would only be one dependency from gpgsm.  It
would look less scary when you "apt install mutt", and it would be less
disk space (because of fewer copies of
/usr/share/doc/*/{copyright,changelog.gz,changelog.Debian.gz,etc…}).

Would that satisfy your goals?  If not, why not?

 --dkg


signature.asc
Description: PGP signature

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[RjY]

RjY wrote:
>It seems in recent unstable the gnupg package has turned into a
>metapackage pulling in the whole gpg suite. Thus the dependency chain
>  mutt -> libgpgme11 -> gnupg -> [lots of stuff]
>is pulling in a lot of stuff I don't need.

As a test I created an empty package to subvert the dependency and see
if anything breaks. The control file was thus:

Package: no-full-gnupg-install
Maintainer: RjY 
Architecture: all
Version: 1
Depends: gpg (>= 2.1.23-2)
Recommends: gpg-agent (>= 2.1.23-2)
Provides: gnupg (= 2.1.23-2)
Description: No full GNUPG install
 This package "provides" gnupg, to avoid libgpgme11
 pulling in the full gnupg suite, until 872368 is fixed.

This allowed installing only gpg and gpg-agent. So far, things still
seem to be working as expected: mutt appears fine, I can still use gpg
to encrypt/decrypt backups, and so on. It would still be good to get
this fixed in src:gpgme, though!

Thanks in advance.

-- 
https://rjy.org.uk/

Bug#872368: gpgme: please adjust libgpgme11 dependency on gnupg package

[RjY]

Package: src:gpgme1.0
Version: 1.8.0-3

It seems in recent unstable the gnupg package has turned into a
metapackage pulling in the whole gpg suite. Thus the dependency chain

  mutt -> libgpgme11 -> gnupg -> [lots of stuff]

is pulling in a lot of stuff I don't need. I use mutt and don't want to
uninstall it, so could the dependency be reduced? It seems splitting up
the gnupg package into smaller pieces is pointless if commonly used
applications force the whole lot to be pulled in.

Many thanks in advance for your consideration.

-- 
https://rjy.org.uk/