Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Daniel Kahn Gillmor]

Control: affects 873499 src:gnupg2

On Mon 2017-08-28 14:36:20 +0200, Yuri D'Elia wrote:
> The gnupg2 package in unstable has been renamed again and split into several
> components.
>
> The "gnupg" package is now the full suite, while "gpg" contains the binary
> itself. To avoid extra dependencies, it would be nice to update the dependency
> to "gnupg | gnupg2 | gpg".

Following up on this again, since the GnuPG packaging split seems to be
stable at this point.

afaict, pass needs only secret key operations, and not network access.

If that's the case, I would recommend that pass switch to:

Depends: gpg, gpg-agent

If someone needs to use their smartcard, they will install scdaemon
themselves.  If pass wants to Recommends: scdaemon, that's also fine.

And please, drop all reference to the gnupg2 package, and avoid all
references internally to /usr/bin/gpg2, preferring just to find "gpg" on
the path.  i'd like to eventually get rid of that dummy/symlink package.

--dkg


signature.asc
Description: PGP signature

Bug#873499: GnuPG package split and interlocking dependencies [was: Re: Bug#873499: Should depend on "gnupg | gnupg2 | gpg"]

[Yuri D'Elia]

On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote:
>> I'd recommend gpg-agent, and suggest gnupg instead.
>
> why?  upstream recommends shipping all the binaries in a single package
> as the standard deployment.  I'm trying to meet them halfway here.
<...>
> I'm willing to keep the split in debian to support narrowly-scoped, tiny
> systems administered by technically-competent people.  But we've got
> enough issues to focus on without encouraging full-blown desktop systems
> that have gpg fail because of missing dependenencies, which is what i
> think would happen if we moved the rest of the suite out of Recommends.
> Do you think that wouldn't happen?

There's one intricate example which I think would be useful for
discussion: what should libgpgme11 do? It currently depends on gnupg,
which installs the full suite. But that's a result of the old package
structure.

I would (personally) make libgpgpme11 depend on gpg only, and move the
burden of the final call to the actual tool facing the user. For
example, notmuch, which uses libgmime which in turn uses libgpgme11 does
that correctly by recommending the agent and gpgsm.

But I do see your point. It's an added burden on the maintainer.

> Thanks for the suggested text.  Can you explain why the package
> Description: should call out secret key use separately from, say,
> network access, or other modules of the suite?

My reasoning is that gpg is supposed to do encryption/decryption and
signing, and if you can't decrypt or sign because you don't have the
agent you're probably wondering what can you actually do with it.

I still see certificate management and network support as extra.

> they most certainly do -- for just one example, in a batch script where
> gpg is invoked a number of times, the long-running dirmngr process can
> cache knowledge about the network between invocations of gpg.

I guess this could happen.

This probably stems for my own usage of gpg itself, which doesn't
involve any network usage on the gpg part.

Bug#873499: GnuPG package split and interlocking dependencies [was: Re: Bug#873499: Should depend on "gnupg | gnupg2 | gpg"]

[Daniel Kahn Gillmor]

[ moving (and setting m-f-t) to pkg-gnupg-maint, which is a more
  appropriate forum for this discussion.  for folks just joining us for
  the backlog, please see https://bugs.debian.org/873499 ]

On Mon 2017-09-11 16:56:39 +0200, Yuri D'Elia wrote:
> On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote:
>> On Mon 2017-09-11 14:28:29 +0200, Yuri D'Elia wrote:
>>> I'd rather go for this route, and recommend gpg-agent from gpg,
>>
>> gpg already Recommends: gnupg, which itself Depends: gpg-agent.
>
> I'd recommend gpg-agent, and suggest gnupg instead.

why?  upstream recommends shipping all the binaries in a single package
as the standard deployment.  I'm trying to meet them halfway here.

The definition of Recommends is:

This declares a strong, but not absolute, dependency.

The Recommends field should list packages that would be found together with 
this one in all but unusual installations.

https://www.debian.org/doc/debian-policy/index.html#binary-dependencies-depends-recommends-suggests-enhances-pre-depends


Upstream's preference is to have all the binaries installed, and gpg
itself is never even tested upstream without having all the other
binaries available.

I'm willing to keep the split in debian to support narrowly-scoped, tiny
systems administered by technically-competent people.  But we've got
enough issues to focus on without encouraging full-blown desktop systems
that have gpg fail because of missing dependenencies, which is what i
think would happen if we moved the rest of the suite out of Recommends.
Do you think that wouldn't happen?

>>  This package contains /usr/bin/gpg itself, and is useful on its own
>>  only for public key operations (encryption, signature verification,
>>  listing OpenPGP certificates, etc).  If you want full capabilities
>>  (including secret key operations, network access, etc), please
>>  install the "gnupg" package, which pulls in the full suite of tools.
>
> This package contains /usr/bin/gpg itself, and is useful on its own only
> for public key operations (encryption, signature verification, listing
> OpenPGP certificates, etc). For operations involving secret keys and
> passphrases, gpg-agent is also required. If you want full capabilities
> (network access, X.509 and CMS and all other command line utilities),
> please install the "gnupg" package, which pulls in the full suite of
> tools.

Thanks for the suggested text.  Can you explain why the package
Description: should call out secret key use separately from, say,
network access, or other modules of the suite?

> I don't oppose the idea of a separated process with different
> capabilities. This is fine for using gpg as a daemon for interactive
> usage.

gpg is not a daemon, it's a one-shot process, which knows how to talk to
various system daemons.

> But on the other side, when all you want to do is use gpg in a batch
> script and it fed stuff which is already on disk, these separate
> processes do hardly anything useful.

they most certainly do -- for just one example, in a batch script where
gpg is invoked a number of times, the long-running dirmngr process can
cache knowledge about the network between invocations of gpg.

  --dkg


signature.asc
Description: PGP signature

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Yuri D'Elia]

On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote:
> On Mon 2017-09-11 14:28:29 +0200, Yuri D'Elia wrote:
>> I'd rather go for this route, and recommend gpg-agent from gpg,
>
> gpg already Recommends: gnupg, which itself Depends: gpg-agent.

I'd recommend gpg-agent, and suggest gnupg instead.

>  This package contains /usr/bin/gpg itself, and is useful on its own
>  only for public key operations (encryption, signature verification,
>  listing OpenPGP certificates, etc).  If you want full capabilities
>  (including secret key operations, network access, etc), please
>  install the "gnupg" package, which pulls in the full suite of tools.

This package contains /usr/bin/gpg itself, and is useful on its own only
for public key operations (encryption, signature verification, listing
OpenPGP certificates, etc). For operations involving secret keys and
passphrases, gpg-agent is also required. If you want full capabilities
(network access, X.509 and CMS and all other command line utilities),
please install the "gnupg" package, which pulls in the full suite of
tools.

> Your previous sentence suggests that you don't want to always having a
> daemon running.  in this sentence, you suggest that you don't like the
> systems that help you to avoid always having a daemon running.  These
> two complaints seem incompatible, unless all you're saying is that you
> simply don't like the idea of separated processes with different
> requirements/capabilities at all.

I don't oppose the idea of a separated process with different
capabilities. This is fine for using gpg as a daemon for interactive
usage. I'm using gpg-agent with pinentry for ssh keys as well, so I'm
not complaining about this. I overall like how these work together.

But on the other side, when all you want to do is use gpg in a batch
script and it fed stuff which is already on disk, these separate
processes do hardly anything useful.

> Can you tell me (probably in a separate report) what unattended
> operation problem you're particularly having, so we can try to get it
> resolved?  surely the fact that unattended operation might involve
> multiple processes instead of a single process isn't the problem in
> itself.

Let's continue this into a separated report then.

Let me know what you think about the revised description and suggested
dependencies.

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Daniel Kahn Gillmor]

On Mon 2017-09-11 14:28:29 +0200, Yuri D'Elia wrote:
> I'd rather go for this route, and recommend gpg-agent from gpg,

gpg already Recommends: gnupg, which itself Depends: gpg-agent.

> mentioning that secret key operations require at least the agent to be
> running in the description.

Please propose alternate text for the package Description.  gpg currently
says:

 This package contains /usr/bin/gpg itself, and is useful on its own
 only for public key operations (encryption, signature verification,
 listing OpenPGP certificates, etc).  If you want full capabilities
 (including secret key operations, network access, etc), please
 install the "gnupg" package, which pulls in the full suite of tools.


gpg-agent's Description says:

 This package contains the agent program gpg-agent which handles all
 secret key material for OpenPGP and S/MIME use.  The agent also
 provides a passphrase cache, which is used by pre-2.1 versions of
 GnuPG for OpenPGP operations.  Without this package, trying to do
 secret-key operations with any part of the modern GnuPG suite will
 fail.

> I'm actually happy that newer versions of gpg do not require dirmngr to
> be running anymore.

No version of gpg has ever required dirmngr to be running just to use
gpg.

However, dirmngr is used for network access.  This means that if you ask
gpg to do something that requires network access, you will need dirmngr
running.  modern gpg itself never talks to the network.

> When using gpg non-interactively, having services start-up
> unexpectedly (especially under systemd activation) is not something
> I'm pleased with.

Your previous sentence suggests that you don't want to always having a
daemon running.  in this sentence, you suggest that you don't like the
systems that help you to avoid always having a daemon running.  These
two complaints seem incompatible, unless all you're saying is that you
simply don't like the idea of separated processes with different
requirements/capabilities at all.

However, there are good arguments for having long-running processes (for
dirmngr, e.g. cached DNS lookups, shared state about known-bad mirrors,
isolation of network access away from sensitive data handling code,
etc).

i'd like to help you resolve the grievances you raise, but they seem
mutually contradictory to me, and in many cases against the improved
engineering practices.  Can you be more specific (probably in a separate
bug report)?

> I remember I filed a bug report about the agent/dirmngr activation. I
> use gpg for batch unattended operations, but it looks like gpg is
> becoming more and more a tool for strictly interactive usage.

gpg has always been more about interactive usage than automated usage.
I agree that it has been a frustrating tool to use for unattended
operations in the past, and that kind of automated workflow seems to
have always been a bit of an afterthought to the upstream project.

However, i think that's actually getting better these days, not worse --
they take bug reports about non-interactive failures more seriously and
fix them more promptly than they used to.

Can you tell me (probably in a separate report) what unattended
operation problem you're particularly having, so we can try to get it
resolved?  surely the fact that unattended operation might involve
multiple processes instead of a single process isn't the problem in
itself.

Regards,

 --dkg


signature.asc
Description: PGP signature

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Yuri D'Elia]

On Mon, Sep 11 2017, Daniel Kahn Gillmor wrote:
> gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
> gpg: can't connect to the agent: No such file or directory
> gpg: agent_genkey failed: No agent running
> Key generation failed: No agent running
> 2 dkg@sid:~$

Since I always had to use the agent, I never noticed. Sorry about that.

> something fancier and more narrowly targeted, they could do something
> like:
>
>   Depends: gpg-agent, gpg
>   Recommends: gnupg

I'd rather go for this route, and recommend gpg-agent from gpg,
mentioning that secret key operations require at least the agent to be
running in the description.

> since i don't believe that pass has any need for network access
> (dirmngr) or X.509 or CMS (gpgsm).  But i don't know pass super well so
> i can't guarantee that this is correct.

pass doesn't fetch external keys.

> I certainly don't want most users to have to think about which
> specific packages they need to install.

I'm actually happy that newer versions of gpg do not require dirmngr to
be running anymore. When using gpg non-interactively, having services
start-up unexpectedly (especially under systemd activation) is not
something I'm pleased with. I remember I filed a bug report about the
agent/dirmngr activation. I use gpg for batch unattended operations, but
it looks like gpg is becoming more and more a tool for strictly
interactive usage.

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Daniel Kahn Gillmor]

On Tue 2017-08-29 11:04:01 +0200, Yuri D'Elia wrote:
> On Tue, Aug 29 2017, Colin Watson wrote:
>>  This package contains /usr/bin/gpg itself, and is useful on its own
>>  only for public key operations (encryption, signature verification,
>>  listing OpenPGP certificates, etc).  If you want full capabilities
>>  (including secret key operations, network access, etc), please
>>  install the "gnupg" package, which pulls in the full suite of tools.
>>
>> pass requires secret key operations, not just public key operations.
>
> I've been using pass with gpg only already since gpg 2.1.23 became
> available using an equivs package to fulfill the dependency. Can you
> make an example of a "secret key operation"? 

an example of a secret key operation in pass is: decrypting an encrypted
password file.  if that is important to you, then you need at least
gpg-agent installed.

> I think gpg's description is misleading.

I'm sorry to hear that.  Can you suggest alternate wording that might be
more suitable?

> gpg can definitely generate and manipulate secret keys by itself for
> example.

I'm pretty sure that this is not true for the modern version of gpg.
You need gpg-agent.  here's a debian installation without gpg-agent,
trying to generate a key:

0 dkg@sid:~$ gpg --gen-key
gpg (GnuPG) 2.2.0; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory '/home/dkg/.gnupg' created
gpg: keybox '/home/dkg/.gnupg/pubring.kbx' created
Note: Use "gpg --full-generate-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: monkeypants
Email address: mon...@pants.example.org
You selected this USER-ID:
"monkeypants "

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: failed to start agent '/usr/bin/gpg-agent': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: agent_genkey failed: No agent running
Key generation failed: No agent running
2 dkg@sid:~$ 


> The only difference is that you need to depend on dirmngr/gpgsm or the
> tools package explicitly.

The simplest thing is just to depend on the gnupg suite, and that is
totally reasonable for the "pass" package if the maintainer prefers it.
(it's also easier for rapid backporting) If the package maintainer wants
something fancier and more narrowly targeted, they could do something
like:

  Depends: gpg-agent, gpg
  Recommends: gnupg

since i don't believe that pass has any need for network access
(dirmngr) or X.509 or CMS (gpgsm).  But i don't know pass super well so
i can't guarantee that this is correct.

however, i've also considered just bundling *all* of the GnuPG suite
into a single "gnupg" package, and breaking out only "gpgv" from the lot
-- that would mean fewer packages installed overall (and therefore
probably fewer complaints from users who like "tight dependencies",
despite the fact that it would mean all the same binaries are actually
installed as the current variant where the binaries are all split into
separate packages).  I know that GnuPG upstream generally prefers to
have all the binaries installed together, so maybe that would be a
better approach if other debian packagers are annoyed by the package
split.

I certainly don't want most users to have to think about which specific
packages they need to install.

let me know what you think we should do!

  --dkg


signature.asc
Description: PGP signature

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Michael Biebl]

On Tue, 29 Aug 2017 06:05:06 +0100 Colin Watson  wrote:
> On Mon, Aug 28, 2017 at 02:36:20PM +0200, Yuri D'Elia wrote:
> > The gnupg2 package in unstable has been renamed again and split into several
> > components.
> > 
> > The "gnupg" package is now the full suite, while "gpg" contains the binary
> > itself. To avoid extra dependencies, it would be nice to update the 
> > dependency
> > to "gnupg | gnupg2 | gpg".
> 
> I'm not convinced that this is a good idea.  gpg's package description
> says:
> 
>  This package contains /usr/bin/gpg itself, and is useful on its own
>  only for public key operations (encryption, signature verification,
>  listing OpenPGP certificates, etc).  If you want full capabilities
>  (including secret key operations, network access, etc), please
>  install the "gnupg" package, which pulls in the full suite of tools.
> 
> pass requires secret key operations, not just public key operations.

I see that Yuri has filed another bug report in this regard (#873498).
Somehow I think the maintainer of gnupg should be involved here before
more such bugs are filed.

So bringing Daniel into the loop here.
I'd be interested to hear if changing the dependencies this way is what
he recommends and if so, if he plans to do a proper MBF for that.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Yuri D'Elia]

On Tue, Aug 29 2017, Colin Watson wrote:
>  This package contains /usr/bin/gpg itself, and is useful on its own
>  only for public key operations (encryption, signature verification,
>  listing OpenPGP certificates, etc).  If you want full capabilities
>  (including secret key operations, network access, etc), please
>  install the "gnupg" package, which pulls in the full suite of tools.
>
> pass requires secret key operations, not just public key operations.

I've been using pass with gpg only already since gpg 2.1.23 became
available using an equivs package to fulfill the dependency. Can you
make an example of a "secret key operation"? I think gpg's description
is misleading.

gpg can definitely generate and manipulate secret keys by itself for
example.

The only difference is that you need to depend on dirmngr/gpgsm or the
tools package explicitly.

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Colin Watson]

On Mon, Aug 28, 2017 at 02:36:20PM +0200, Yuri D'Elia wrote:
> The gnupg2 package in unstable has been renamed again and split into several
> components.
> 
> The "gnupg" package is now the full suite, while "gpg" contains the binary
> itself. To avoid extra dependencies, it would be nice to update the dependency
> to "gnupg | gnupg2 | gpg".

I'm not convinced that this is a good idea.  gpg's package description
says:

 This package contains /usr/bin/gpg itself, and is useful on its own
 only for public key operations (encryption, signature verification,
 listing OpenPGP certificates, etc).  If you want full capabilities
 (including secret key operations, network access, etc), please
 install the "gnupg" package, which pulls in the full suite of tools.

pass requires secret key operations, not just public key operations.

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#873499: Should depend on "gnupg | gnupg2 | gpg"

[Yuri D'Elia]

Package: pass
Version: 1.7.1-3
Severity: normal

The gnupg2 package in unstable has been renamed again and split into several
components.

The "gnupg" package is now the full suite, while "gpg" contains the binary
itself. To avoid extra dependencies, it would be nice to update the dependency
to "gnupg | gnupg2 | gpg".

-- System Information:
Debian Release: buster/sid
 APT prefers unstable
 APT policy: (900, 'unstable'), (800, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pass depends on:
pn  gnupg2 | gnupg  
ii  tree1.7.0-5

Versions of packages pass recommends:
ii  git   1:2.14.1-2
pn  gnupg2
pn  qrencode  
pn  xclip 

Versions of packages pass suggests:
ii  libxml-simple-perl  2.24-1
ii  perl5.26.0-5
ii  python  2.7.13-2
ii  python3 3.5.3-3
pn  ruby