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 <mon...@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 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
