Done. Thank you for stopping by.

Pound/gitweb.cgi was killed by the OOM killer, probably due to a memory leak. Thanks for letting us know.

I guess for older releases it is less relevant to have very accurate version information. From now on this is more a regular maintenance task than a unit of work, so I am closing it.

Gave it a head-start.

Without a committment to code review workflows, this is meaningless.

This is probably broken since Werner enabled descriptor passing by default in 5090f6f24. The analysis in https://dev.gnupg.org/T2919#99901 is correct, but it's not enough to put the operational error in the right place. Also, the calls to _gpgme_wait_one have to be replaced by _gpgme_wait_one_ext. The change overall will be somewhat destabilizing.

Won't fix in favor of decentralisation.

Now you can do this:

I know exactly what you mean, but werner disagrees so that's not going to happen.

The patch was accepted, not abandoned, but the phabricator review workflow doesn't make it easy to change the state without using the arc command line tool. The quickest way to close the issue without review is to claim it myself and "abandon" it. Sorry for the confusion.

No new tools.

My comment was only in response to this:

gpgme_data_t are first class objects with an API to create and destroy them, and some articulated rules how to use them (only one thread at a time). gpgme_key_t objects can not be created but only be returned with gpgme_op_keylist_next.

It's been a month since last release, no error reports so far.

If the certificate is signed by a trusted root CA, doesn't that mean that we at least trust the URLs in the certificate chain for CRL and OCSP access?

No response.

The server was replaced due to failure. New IP addresses are: 109.235.43.70 and 2001:678:340::70. I updated the DNS entries, and they seem to have propagated (but your local cache may still refer to the old entries).

Techniker ist informiert.

One way to prevent this mechanically would be to store an identifier for the gpgme_ctx_t object from which the gpgme_key_t object came inside the gpgme_key_t object itself, and then verifying that the keys really came from the same context. But such edge cases seem to be quite rare, and I'd hope that most developers make a tacit assumption that objects stemming from a specific context can not be repurposed in a different context ad lib.

Why wasn't the natural thing for you to do gpgme_op_import?

This should be fixed by a0cc6e01. Just use the new gpgme_op_delete_ext operation with GPGME_DELETE_FORCE flag.

To make this work again, I think gpg-agent needs to cache the public key or support batch-operations (which would require some restructuring in gpg to request such a batch-operation).

Turns out that 2963 fixed this at the same time.

You are chasing a bit of a ghost there. The operation was originally added for GPGSM to support the IMPORT --re-import command that removes the ephemeral flags from certificates that were previously imported as a side-effect of an external keylist operation. That's where the footnote comes from.

Well, we need more information to proceed on this. Maybe run with GPGME_DEBUG=9 to see why it fails.

Most of your concerns seem to come from the "move keys" wording, which I removed. I also fixed the return values. The footnote is specific to X.509 peculiars.

Done in 274609ba.

Cool. I tested building without and with coverage report enabled.