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.
