works for me, thanks

Good morning,
I stumbled upon this when digging through old Debian bug reports against 1.4 and checking whether they still applied to 2.4. This one really still applies.

This is still broken on 2.5.5.

this marked as fixed in 2.4.7. However afaict only one of the two patches made it to STABLE-BRANCH-2-4, b1857a2836c9a91ef4e359ef7ba949b54c77219d did not.

Taking a bigger sample of keys from the same domain and doing the same testing shows that the signature by B0D589D46708EC99 is removed on all keys.

Thank you Daniel for forwarding this. To get the attribution right: I did not find the issue, Todd Zullinger reported it on https://lists.gnupg.org/pipermail/gnupg-devel/2024-October/035661.html

Werner wrote:

We will bump the gpgme core version to 2.0 to indicate this split despite that there will be non-ABI/API incompatibility.

Hello,
I have a hard time to agree that is the right thing for gnupg to throw an error if it successfully imported a revocation certificate for an expired key. This is a meaningful (and not useless) change even if the key is expired.

In T7226#189443, @jukivili wrote:

This patch should fix the issue:

0001-mpi-ec-inline-reduce-register-pressure-on-32-bit-ARM.patch4 KBDownload

This already shows with 9d909cb67e70fd792926ac1e2ab305b2cc96bc27 which initially added ec-inline.h. (Reproducing with old versions like this one requires cherry-picking 693ffa145378682229473b0e811a9cea7c4d307a since otherwise NEON support is disabled at configure time due to implicit functions.)

Any chance this could also be fixed in the 2.2.x series, where it seems to have been introduced in 2.2.42?

Ditto for ksba and assuan.

The gcrypt change works for me. Thanks!

Just to clarify: I personally think it would be perfectly fine to say that AM_PATH_* is only supported when AM_PATH_GPG_ERROR is also used. Adding an invocation AM_PATH_GPG_ERROR is not a great hassle and alternatively pkg-config/pkgconf exists and works perfectly fine (and is a lot faster).

Hello Werner,
the above is an excerpt from the exim log, I do not think the full bounce is more enlightening, vsrv21575.customer.vlinux.de got 550 from ellsberg.gnupg.com after " MAIL FROM:<ametzler@bebt.de>":

The mail server is misconfigured. no SPF <> not allowed.

Sorry for the fallout and thank you for taking care of it.

In T6309#166019, @ametzler1 wrote:

Missed some, will post an updated patch.

Missed some, will post an updated patch.

In T6285#165459, @gniibe wrote:

Now, the use of AM_PATH_GPGME_PTHREAD shows warning. Also I update the documentation.

Something like this?

In T6288#165435, @werner wrote:

Bootstrapping is an issue. Recall that pkg-config is not a simple program but requires the use of glib (which depends on libffi, libmount, libpcre) - catch-22. Makes building GnuPG on AIX not actually easy.

FWIW I would vote for a) "document gpgrt-config in detail" and suggest using pkg-config (variant) for direct invokations. There seems to be little benefit in investing effort/complicating gpgrt-config when pkg-config works fine.

thank you, works for me.

Thank you, looks good to me.

@gniibe - Thanks for the quick response. It now works for me.
cu Andreas

the pushed fix breaks when libgpg-error does not require special CFLAGS, i.e. when @GPG_ERROR_CFLAGS@ expands to an empty string:

bernhard added a comment.Mon, Sep 5, 6:05 PM

If it is was broken for you and works now, let us know here.
if "lists." still is there in email addresses somewhere, please also list.

In T5816#154715, @ikloecker wrote:

Try gcrypt-devel@gnupg.org, i.e. without the lists subdomain.

Recently, the gnupg.org mailing list manager started to prepend the lists. subdomain to the List-Id (which caused my email filters to fail) and to everything else. Probably due to an accidentally changed configuration.

This works for me:

This bug has been assigned CVE-2019-12904. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12904

gniibe wrote: