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,

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.

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

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'm sorry to hear that.  Can you suggest alternate wording that might be
more suitable?
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: monkey@pants.example.org
You selected this USER-ID:
    "monkeypants <monkey@pants.example.org>"

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 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!

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

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.

pass doesn't fetch external keys.

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.

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

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.

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.

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)?

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,

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). 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.

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.

Let's continue this into a separated report then.

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

[ 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 ]

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?
Description: should call out secret key use separately from, say,
network access, or other modules of the suite?

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

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.

<...>

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.

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.

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.

Control: affects 873499 src:gnupg2

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.

We believe that the bug you reported is fixed in the latest version of
password-store, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 873499@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Colin Watson <cjwatson@debian.org> (supplier of updated password-store package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Tue, 27 May 2025 11:57:30 +0100
Source: password-store
Architecture: source
Version: 1.7.4-8
Distribution: unstable
Urgency: medium
Maintainer: Colin Watson <cjwatson@debian.org>
Changed-By: Colin Watson <cjwatson@debian.org>
Closes: 873499
Changes:
 password-store (1.7.4-8) unstable; urgency=medium
 .
   [ Paride Legovini ]
   * d/control: Replace dependency on gnupg with gpg, gpg-agent (closes:
     #873499).
Checksums-Sha1:
 66501afd62a964f4581695a2dcb1957f43ee144e 2186 password-store_1.7.4-8.dsc
 9957d8dcd7259396e8b6b78a92a8800ea402fccf 8280 password-store_1.7.4-8.debian.tar.xz
Checksums-Sha256:
 1f93c658099ac732ba43e11f9833db0644d3df0f3554f1d8bd229e5e7219d4ae 2186 password-store_1.7.4-8.dsc
 317ad8794801216db980da8ef8c3aca8d79969058956abbd9b0af781a64b7d7e 8280 password-store_1.7.4-8.debian.tar.xz
Files:
 fa4365195ea60e2b9c0d203b172be534 2186 admin optional password-store_1.7.4-8.dsc
 701546b6bd2e211ac280cefdb3e588c9 8280 admin optional password-store_1.7.4-8.debian.tar.xz
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEErApP8SYRtvzPAcEROTWH2X2GUAsFAmg1mrMACgkQOTWH2X2G
UAscDg/+LvT3uraAQHqVCsP/LlXBcRW8g3pBmzrfMYwHiZxrZ2YLzDkIU6gTFKJq
ttu4XkUArCkHn/k+yYPDsb70p668N+EJHMnC/IeRvp4C/f+u8FP4RvLeyScOJw5t
hSe2Jr1pqNsbbyvqNju7QywF1B01cuI8Yi/KJKBKYvpaHMPTqc9K4edd+3WmLh56
hZ07ONBHGf/xoYxGbDP8YL/MXy30A1g9Fz/3q0CYRg/QjY7vedNA1U8gG2tZpLoi
f6zEOOYGwkkTISieoxkOpnbC8gC8UWirqGyDeN8Ps0l5KNH1OBQEj4lc6PkzR28J
geFXGRq6gRvrHUlmGiY3aaDDANOWSb0BMc4RMSyBCF3+vW2VG+sb8sshYRsIk1YS
nhAfnSVjt23W8Fb9r0wsK4/jN2AZ8B2gXk5rDFyV4N6u1bOMvbpcdjEX+Wa2i3pI
7ppiaETf1ojOS2UTVX8O+LXdSC0IQwRNxVMUsUUFk9/xtCEYoUmMoGLpX5npKKcE
9ol/3uEvJcYXmkW0lJcXY8a+/rEdofuSCmNXKlRgyjOEGLYx5AvoO1BDdkfz43VN
4h+qFHVPxtJQTj2jorHeQbv8A9ktCPe/UYhfVKqyBLSUrIggHTpaqiM5aSOc4CxV
bjjZgZqtbDJNiWlbOnr58rfZp7KxX/820X6owpOHIExDTvYaWpw=
=lo2q
-----END PGP SIGNATURE-----