Page MenuHome GnuPG

saurik (Jay Freeman (saurik))
User

Projects

User does not belong to any projects.

User Details

User Since
May 1 2020, 11:49 PM (203 w, 6 d)
Availability
Available

Recent Activity

May 18 2021

saurik updated the task description for T5440: _DARWIN_C_SOURCE kind of "must" be 1, not "900000L".
May 18 2021, 4:27 AM · MacOS, libgcrypt, Bug Report
saurik added a comment to T5440: _DARWIN_C_SOURCE kind of "must" be 1, not "900000L".

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

May 18 2021, 3:14 AM · MacOS, libgcrypt, Bug Report
saurik created T5440: _DARWIN_C_SOURCE kind of "must" be 1, not "900000L".
May 18 2021, 3:10 AM · MacOS, libgcrypt, Bug Report

Apr 13 2021

saurik added a comment to T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.

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!

Apr 13 2021, 4:49 AM · MacOS, libgcrypt

Mar 30 2021

saurik added a comment to T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.

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

Mar 30 2021, 1:08 PM · MacOS, libgcrypt
saurik added a project to T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt: libgcrypt.
Mar 30 2021, 12:41 PM · MacOS, libgcrypt
saurik renamed T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt 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 · MacOS, libgcrypt
saurik added a comment to T5268: macOS getentropy.

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

Mar 30 2021, 12:34 PM · libgcrypt, MacOS
saurik updated the task description for T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.
Mar 30 2021, 12:29 PM · MacOS, libgcrypt
saurik created T5375: getentropy usage is forbidden by Apple, but is now being forced by libgcrypt.
Mar 30 2021, 12:28 PM · MacOS, libgcrypt
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.

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

Mar 30 2021, 10:35 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.

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

Mar 30 2021, 8:23 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.

@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? :(

Mar 30 2021, 8:19 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt
saurik updated the task description for T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
Mar 30 2021, 8:14 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.

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

Mar 30 2021, 8:10 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.

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

Mar 30 2021, 6:53 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt
saurik added a comment to T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.

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

Mar 30 2021, 6:43 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt

Mar 26 2021

saurik created T5365: --with-libgpg-error-prefix doesn't affect gpgrt-config path detection.
Mar 26 2021, 7:07 AM · MacOS, gpgrt, Cross-Compiler, libgcrypt

Feb 9 2021

saurik created T5289: gen-lock-obj.sh uses echo -n from /bin/sh, which echos "-n".
Feb 9 2021, 12:01 AM · MacOS, gpgrt, Bug Report