Page MenuHome GnuPG

getentropy usage is forbidden by Apple, but is now being forced by libgcrypt
Closed, ResolvedPublic

Description

Apple explicitly considers getentropy to not be a public API, and refuses to publish binaries to their App Store (at least iOS, maybe also macOS but I haven't checked yet) if you try to link against this symbol (citing ITMS-90338: Non-public API usage). This isn't so big of a deal, because I just pass ac_cv_func_getentropy=no to configure and go about my day... until 6cb0faf6ceec5b2e799e6fb5f04b85d135a7da9b, which for some reason has a one-off/haphazard check that forces a #define of HAVE_GETENTROPY and attempts to use a weak_import to proactively pull this forbidden symbol into my application :(. If configure determines this function isn't available, this function probably shouldn't be used, right? ;P This is forcing me to make a tactical retreat to an old version of gcrypt so I can publish my application.

Revisions and Commits

Event Timeline

saurik created this object in space S1 Public.
saurik updated the task description. (Show Details)
saurik renamed this task from getentropy is forbidden on macOS but is now being forced by libgcrypt to getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.Mar 30 2021, 12:34 PM
saurik mentioned this in T5268: macOS getentropy.
saurik updated the task description. (Show Details)

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

IIUC... Could you please try this patch?

diff --git a/random/rndlinux.c b/random/rndlinux.c
index a7a78906..c20c5d4c 100644
--- a/random/rndlinux.c
+++ b/random/rndlinux.c
@@ -35,10 +35,13 @@
 #if defined(__APPLE__) && defined(__MACH__)
 #include <Availability.h>
 #ifdef __MAC_10_11
+#include <TargetConditionals.h>
+#if !defined(TARGET_OS_IPHONE) || TARGET_OS_IPHONE == 0
 extern int getentropy (void *buf, size_t buflen) __attribute__ ((weak_import));
 #define HAVE_GETENTROPY
 #endif
 #endif
+#endif
 #if defined(__linux__) || !defined(HAVE_GETENTROPY)
 #ifdef HAVE_SYSCALL
 # include <sys/syscall.h>
gniibe triaged this task as Normal priority.Apr 1 2021, 6:39 AM
gniibe changed the task status from Open to Testing.Apr 13 2021, 3:16 AM

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!