You are coming pretty late to the party ;-). Since 2.1.0 we don't use the ancient keyserver helpers anymore but reworked the entire network access. I even doubt that I can still test with a 2.0 version.

We have two or three other open issue which I would like to address before a release. FWIW, release ticket is T5305.

Do what ever you want with _gcry prefixed functions - this is never considered an API or ABI break. There are some exceptions for internal functions used by macros but those are clearly marked.

Good to hear that it works now.

A PATH with spaces is too Windowish (or macOS). IIRC, we had once checks that the used directories have proper names; we can expect this for build environment. Spaces in file names are horrible from a security POV it is just to easy to get things wrong (hello ssh).

I already backported the above for Fedora so I am not in hurry now. But I believe others might hit the same issue.

@werner Can you comment about bugfix release?

These functions are internal to library and, for example, on linux/windows builds are not externally available.

Admin here. I'm sorry your replies did not make it to this site but somewhere got stuck. So copying them for completeness:

In https://github.com/rust-random/getrandom/issues/38 they seem to have decided to use SecRandomCopyBytes on iOS, while in https://github.com/LuaJIT/LuaJIT/issues/668 they pushed https://github.com/LuaJIT/LuaJIT/commit/787736990ac3b7d5ceaba2697c7d0f58f77bb782 which I believe falls back to /dev/urandom. In both cases, they are only staring at iOS as an issue; though, it could be that using Rust at the same time as targeting an official macOS application are both rare enough to allow this to have gone two years without a rejection... making this weak_import hack not happen on iOS might be sufficient. If you do this, I recommend checking for TARGET_OS_IPHONE, not TARGET_OS_IOS, as (despite the somewhat hardware-specific sounding name) the former also encompasses tvOS and watchOS (which, if anything, will have stronger checks); I'd personally be satisfied with just some way of manually disabling getentropy by force, though (as I had been previously using ac_cv_func_getentropy=no).

So, I actually just filed an issue about this work: T5375, and then found this opposing task while following through on the various commits ;P... Apple actually forbids usage of getentropy in applications they publish to their App Store (citing ITMS-90338: Non-public API usage), and so there needs to be a way to disable this weak_import. FWIW, I'm not sure if this is only on iOS or on macOS as well (I haven't gotten around to trying to publish a macOS build with the new libgcrypt yet).

Very strange. Both logs show no error.

Sorry, first log was without API.
This log includes API calls.

Here we go. ;-)

Just drag and drop it into the input field. There is also a little cloud icon that makes this explicit.

Thanks for this very quick reply.

Sorry, but we are a security software. If you give any application that you run on your system root privileges then that is not a secure behavior. This kind of stuff has been deprecated with Windows Vista. Yes we changed the error to a warning as it was too zealous. I agree. It is not our place to educate users. But users should change your operating procedures. You should not handle protection worthy data on a system without privilege seperation.

@gniibe Note that you also need to at least add the semicolons, as BSD sed is trying to parse "gp}" as substitution flags (which, honestly, makes more forward-compatible sense than GNU sed's behavior...).

Mmh, all these issues should be fixed with the most recent versions.

Or, if we keep the code of newline (so that it will eventually support path with a space in future):

Thank you. Sorry for the use of GNU sed extension. It could be just a whitespace, if it's OK not to support path having a space.
sed -n -e "/^libraries/{s/libraries: =//;s/:/ /gp}") should work.

@gniibe OK, so... "worst case": I guess this worked? ;P

@gniibe Actually, I just realized that neither of the commands I provided work, as I failed to notice you were trying to also replace :'s with newlines (as I guess libraries from clang can return multiple paths). I'd momentarily edited my comment to just try to add back your colon replacement, before remembering you can't do that either: \n is a GNU sed extension. Hilariously, I'm always in contexts where I can assume I'm using bash (which isn't ok for configure), so I've never bothered to learn a technique that doesn't involve $'\n'... do you have a strategy for doing this replacement? :(

@gniibe Ah yeah, that was the commit I meant to reference when I said "--maybe caused by --", but then forgot to go back and fill in the commit hash ;P.

I wonder if this works in your use case:

diff --git a/m4/gpg-error.m4 b/m4/gpg-error.m4
index d910754e..aeedaf10 100644
--- a/m4/gpg-error.m4
+++ b/m4/gpg-error.m4
@@ -65,7 +65,7 @@ AC_DEFUN([AM_PATH_GPG_ERROR],
   min_gpg_error_version=ifelse([$1], ,1.33,$1)
   ok=no

If it is new, it may be the change of this commit rC8e3cd4c4677c: build: Update gpg-error.m4.

(To be clear, I also know enough about autoconf to not have been like, blocked from upgrading by this: overriding ac_cv_path_GPGRT_CONFIG worked, but I can't believe that's the intended way for someone to ensure they get the correct path for gpgrt-config ;P.)

@gniibe The problem is that the check seems to just find gpgrt-config from the path; like, I'm already passing --prefix and --host, but it is deciding to just arbitrarily pick up my system-wide copy of /usr/local/bin/gpgrt-config. Here's my entire configure invocation from that earlier failed build: note that the --prefix is the same as --with-gpg-error-prefix.

We are in transition from old gpg-error-config to new gpgrt-config. <-- This is the cause, while I tried to cover most use cases.

The optimization introduced for curve 25519 and curve 448 en-bugged for usage of direct MPI.

Guys, no offense, but you screwed things up a lot.
You should have put some warning within installer 3.1.15 when it updates files, or at least make an error message more verbose.
Right now it is totally not obvious what to do (move from where to where{F2234144}) except for rolling back to previous version of Kleopatra.
For example, I a PC user with administrator account only (and it will remain forever), so?

Yet another identify theft scam committed by clang.

This patch should work if configure properly detects need for extra underscore on C symbols:

This patch should work if configure properly detects need for extra underscore on C symbols:

Please look at the code:

Sorry to dig up an old report...

Sorry to dig up an old thread...

Here's the patch I am using for the Apple M1: libgcrypt-darwin.patch. The patch is public domain so anyone is free to use it.

This is kind of a hack, but this patch:

yep, Should be fixed in libgpg-error/src/w32-gettext.c unless we want a way to retrieve the meat data. We can also and faster fix this in gnupg proper.

Hey @wener.. As I mentioned in the original post, there's a default-new-key-algo setting... Is it still not possible to use specify something like "rsa4096/cert,rsa4096/encr,rsa4096/sign,rsa4096/auth"?? Would love to see some progress on this. Glad to help test.

--clearsign may only be used for plain text documents due to line ending conversion etc.