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
signature.asc
Description: PGP signature
