Jun 21 2024
Now also done for libksba.
Feb 29 2024
Nov 15 2021
Let me clarify the use case of gpg-error.m4.
Sep 8 2021
Please talk to the KDE folks who develop Craft. We do not support building anything with Craft. Check out gpg4win (https://dev.gnupg.org/source/gpg4win/) to see how we build our products on Windows.
Aug 30 2021
Aug 13 2021
Apr 12 2021
Mar 31 2021
I was wrong in my last comment. Escaping by another \ is needed.
Mar 30 2021
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).
@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...).
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.
Mar 26 2021
Feb 17 2021
Feb 12 2021
Jan 29 2021
Jan 26 2021
Jan 23 2021
Jan 21 2021
Jan 20 2021
Thanks for report. I reproduced this by building i386 with optimizations disabled "-O0" (gcc 10). With normal optimization level such as "-O2", the issue does not appear.
Dec 5 2019
I believe the problem was fixed in the master of pinentry with newer gpg-error-config and libassuan-config which support cross build better.
Jun 6 2018
May 18 2018
Mar 30 2017
May 18 2013
In order to work around this potential bug I do the following at the moment:
- Store: (a) Export the ASCII-armored *secret* key together with its subkeys. (b) Export the ASCII-armored *public* key together with its subkeys.
- Restore: (a) Import the ASCII-armored *public* key together with its subkeys. (b) Import the ASCII-armored *secret* key together with its subkeys.
The actions [1.(b)] and [2.(a)] should not be necessary if there was not this
potential bug.
I further tried to find the action that causes the potential bug with an another
test key as follows:
- Create a certify-only RSA4096 primary key.
- Store the public keyring with: (a) cp ~/.gnupg/pubring.gpg{,XXX}
- Export the secret key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xEEE9979BE8C80E95.pub.asc.txt --
export 0xEEE9979BE8C80E95
- Export the public key to an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --output 0xB6BF97893ACA0C17.pub.asc.txt --
export 0xB6BF97893ACA0C17
- Delete the public and secret key with: (a) gpg --delete-secret-and-public-keys 0xEEE9979BE8C80E95
- Import the secret key from an ASCII-armored file with: (a) gpg -v --status-fd 1 --armor --import 0xEEE9979BE8C80E95.sec.asc.txt
- Compare the previously stored public key against the new one with: (a) diff -q ~/.gnupg/pubring.gpg{,XXX}
- Repeat action 1. to 7. by: (a) Adding a sign-only RSA4096 subkey. (b) Adding a encrypt-only RSA4096 subkey. (c) Change the expiry date of the encrypt-only RSA4096 subkey.
ERROR: *Changing the expiry date*, exporting, purging, importing the primary key
with its 2 subkeys makes the first sign-only RSA4096 subkey disappear from the
pubring.gpg file but not from the secring.gpg file.