Unfortunately, even building for two Python versions is a bit of a hassle with the existing autoconf framework for Python. I did that when porting the Python bindings back to Python2 after we decided to also support 2 so that people could start to use our bindings even if they still need Python2. I don't see us extending it for more versions.

Merged, thanks for the reminder.

Hi. You can start gpg-agent using gpgconf --launch gpg-agent. I'll delegate the systemd questions to Daniel.

Unfortunately, I cannot find a better tool that seems mature, maintained, and packaged for Debian. Maybe it is best to improve the current tool.

Implemented in c4506f624ed6854aa0ba1629aa2d1d43eb26900d.

This is not about faked-system-time, nor about misconfigured systems, it is about gpg using uninitialized or invalid data. This is one instance of that problem, and there could be more. I'm sorry if I failed to communicate this.

We are in feature freeze and changing the status code of gpgv will likely cause problems for gpgme. We need to defer this.

I encountered this bug again in production while creating keys on an air-gapped system that had the wrong time zone configured. I consider this kind of problem grave and embarrassing, but we failed to agree on a way to fix it in the foreseeable future.

I'm closing this. Feel free to reopen the bug with more information.

That is correct, gpg-agent does not daemonize on Windows if --daemon is given, it is simply not implemented.

In T3284#100822, @werner wrote:

No. gpg-agent is a different implementation of the ssh-agent protocol than ssh-agent. Making the keys persistent is on purpose.

Fixed in e7fc6e3bf0eb6ffe53e1f099d28ce45cef4a8a87.

Implemented in da91d2106a17c796ddb066a34db92d33b21c81f7.

But that is not very user friendly. I wasn't aware of that way to list and delete keys for example.

There are two issues here.

Fixed in b231959728a0056094134e0fca8cc916c24ef37e.

User IDs of length zero do seem to be in compliance with RFC4880.

Sorry, I went through considerable length to reproduce this, but failed.

I just verified that this is indeed fixed.

In T2923#100519, @dkg wrote:

including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.

this discrepancy is easily explained. You are entering a date that is interpreted as UTC, and it is echoing it back using your local time zone. PST is UTC−8:00, matching the output.

Can you provide samples that highlight the problem?

Another reoccurring concern is lingering agents spawned in test suites. See, e.g. a discussion from this week: https://github.com/pazz/alot/pull/1081#issuecomment-315131053

Sorry, I expressed my concern poorly. gpg does recognize the keys as being expired/revoked, but this is not reflected in the exit code of the gpg/gpgv process.

"gouttegd (Damien Goutte-Gattat)" <noreply@dev.gnupg.org> writes:

I've just pushed the two fixes. `GNUPGHOME` is now set to the tests directory when running the tests and `gpg-connect-agent` is now looked for in `PATH` at runtime.

When the tests are run, Scute now contacts the agent intended for the tests instead of any agent running on behalf of the Jenkins user. And so the tests pass or skip appropriately.

I see several problems here: