[pkg-gnupg-maint] Bug#950836: Bug#950836: Bug#950836: gpg-agent: generator 90gpg-agent and user with no home crontask generate annoying logs

[Daniel Kahn Gillmor]

On Fri 2020-03-06 09:09:11 +0100, Laurent Wafflard wrote:
> Yes it would be better !
> With the Q&D stderr redirect, some logs are not catched by the logcheck 
> rules of gpg-agent, we added locally:
>      ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: 
> Listening on GnuPG cryptographic agent and passphrase cache \(access for 
> web browsers\)\.$
>      ^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: 
> Closed GnuPG cryptographic agent and passphrase cache \(access for web 
> browsers\)\.$

Please propose new logcheck patterns in a separate bug report, ideally
with a patch, or perhaps as a separate file!  your e-mail program
appears to line-wrap this stuff, and regexps aren't very useful if
they've been mangled.

> but it would become useless if gpgconf will be executed only for users 
> with existent home.

I don't want to predicate running gpgconf on whether the homedir exists,
because it's not clear to me that this is a specific requirement.

the canonical upstream way to query the gpg suite's configuration is
gpgconf, and i'm trying to use the canonical upstream interfaces rather
than crafting novel ones that i (or someone else) will then have to
maintain.

That said, i agree that the spurious warnings don't seem relevant.
Rather, the environment generator shouldn't try to claim that gpg-agent
should be the active ssh-agent socket if it knows that gpg-agent is
somehow broken.

So i've wrapped the test in question in a "gpgconf --check-programs"
command instead.  Please follow up here (feel free to reopen the bug
report) if this doesn't solve the problem for you.

Regards,

   --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20200309/9ba2d05c/attachment.sig>