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
