Note: I believe this issue might affect multiple other GnuPG projects.

I'm sorry I disappeared on this issue for two weeks; I just got reminded of it by seeing the e-mail with the status change. I've updated to the latest gcrypt (which is the commit with the patch, now pushed to the repository) and was able to upload this to Apple without it being flagged; thanks!

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).

@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...).

@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.

(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.