Excuse me you are right of course. man gpgconf | grep quot says it all.

man gpg | grep quote nor man gpgconf | grep quote does not tell anything about it. I recognized the single opening quote of "string at post processing the output of gpgconf --list-options to generate a gpgconf.conf template. I just expected a closing quote for "string".

From which version on there will be global config files? The only info I found was about /etc/gnupg/gpgconf.conf and /etc/skel/.gnupg/* to manage presets.

@werner Hmm, okay. So I have tested the wrong thing. To me /etc/gnupg/gpgconf.conf looked very much like a global config file I was supposed to test. I have looked at /etc/gnupg, found the example gpgconf.conf and played around with it. It had some effects (see above), so I assumed that it should work. Since it's obvious from my tests, that it doesn't really work as documented anymore, all corresponding code should be removed entirely (or fixed if it should be kept for backward compatibility).

ikloecker: gpgconf.conf ist not anymore used since we have the global config files.

With /etc/gnupg/gpgconf.conf

[empty lines and comment lines]
*	gpgsm	verbose				[no-change]
	gpgsm	quiet				[no-change]
	gpgsm	debug-level			[no-change]
	gpgsm	log-file			[no-change]
	gpgsm	include-certs			[no-change]
	gpgsm	compliance			[no-change]
	gpgsm	default-key			[no-change]
	gpgsm	encrypt-to			[no-change]
	gpgsm	keyserver			[no-change]
	gpgsm	disable-dirmngr			[no-change]
	gpgsm	auto-issuer-key-retrieve	[no-change]
	gpgsm	p12-charset			[no-change]
	gpgsm	disable-crl-checks		[no-change]
	gpgsm	enable-crl-checks		[no-change]
	gpgsm	disable-trusted-cert-crl-check	[no-change]
	gpgsm	enable-ocsp			[no-change]
	gpgsm	disable-policy-checks		[no-change]
	gpgsm	cipher-algo			[no-change]

all options are correctly flagged as "no change" in the output of gpgconf

More weirdness. With gpgconf (GnuPG) 2.2.34-beta23 I get:

--apply-defaults is an obsolete option because we now have global config files. I would also like to get rid of --debug-level but that won't be easy. Using --debug LIST_OF_DEBUG_FLAGS is a more versatile way of specifying debug options.

Nope. The double quote indicates a string. See the man page.

Thank you, applied.

Potential fix posted here: https://invent.kde.org/pim/kleopatra/-/merge_requests/11

Thanks for looking into this, @gniibe! over on https://bugs.debian.org/1003313 Helmut is asking for a re-consideration because he wanted to match arm-linux-musleabihf. Would you be ok with a change like my proposal rE371d1c952297f781277b979a4662859ec80fe836 (on branch dkg/expand-musl), that expands *-*-linux-musl to *-*-linux-musl* ?

After commenting out the options that gpgconf 2.3 complains about I get:

$ gpgconf --version
gpgconf (GnuPG) 2.3.5-beta17
Copyright (C) 2021 Free Software Foundation, Inc.
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

I tried to see what gpgconf from master says, but I only get

$gpgconf --list-options gpg
gpgconf: unknown option 'try-secret-key' at '/etc/gnupg/gpgconf.conf', line 95
gpgconf: unknown option 'reader-port' at '/etc/gnupg/gpgconf.conf', line 96

This also doesn't look right:

The following looks very much like a bug.

Example:
/etc/gnupg/gpg.conf:

default-key B81CE112B26A8EA8BE7B95D2E375339BF4C51840

With rG8c878ae4c9dfa9fe26aa15f4f9db3e86833575e9 some rules for allow-mark-trusted were removed from doc/examples/gpgconf.conf, but the comments below which are supposed to explain the example rules still talk about allow-mark-trusted.

sorry, I'm a bit confused now and probably everything I wrote above is incorrect.

thanks for approving account.
build error happens in automatic configuration (when --enable-ppc-crypto-support is omitted from ./configure) and -mcpu=powerpc64le, -mcpu=power8 or power9 or -mpower8-vector flags are not passed to compiler.

Backported to 2.2, too.

On behalf of @gyakovlev (pending approval for his account):

[03:05:23]  <@gyakovlev>  AC_DEFINE(HAVE_COMPATIBLE_CC_PPC_ALTIVEC,1,
[03:05:23]  <@gyakovlev>         [Defined if underlying compiler supports PowerPC AltiVec/VSX/crypto intrinsics])
[03:05:34]  <@gyakovlev> they should definitely check for __POWER8_VECTOR__ 1
[03:05:44]  <@gyakovlev> it's not plain altivec
[03:06:52]  <@gyakovlev> that power check should check for __POWER8_VECTOR__
[03:06:52]  <@gyakovlev> not only for what they check already.
[03:08:59]  <@gyakovlev> it probably should be checked after __powerpc64__ or instead of it.

Looks like it's triggered if e.g. -mcpu=power9 isn't in CFLAGS.

Build log here:

You'll have to talk to the people you got pinentry-mac from.

I don't know about pinentry-mac but it seems to be another name for
one our our regular pinentry variants.

We provide lots of different flavors of pinentry, but we do not provide pinentry-mac. You'll have to talk to the people you got pinentry-mac from.

Thanks for diving into the history of that code.

Here is the backport to 2.2:

In the original code, register_trusted_keyid is used in keygen.c, so that it updates user_utk_list, thus, will be into utk_list.
This should be done, by adding the keyid to utk_list directly.

Things have been a bit buggy here (probably, since the beginning).
In g10/trustdb.c,

Let me clarify:

• It was on 2003-11-01 (ChangeLog is on 2003-10-31 probably in US): rG5c37fd90bf81: * trustdb.h, trustdb.c (register_trusted_keyid): New. Adds a keyid to the

Thank you, @gniibe ! i'm applying your change to the debian packaging as 1.43-2. i'll let you know if it doesn't satisfy the folks trying to crossbuild debian on top of musl.

Thank you.
Applied.

Thank you for forwarding from Debian.

Thanks Werner! As I'm on NetBSD I was able to use ktrace instead, and you can find the output at https://termbin.com/zm2c. (It expires in 1 month. Let me know if you would like me to paste the full output here.)

That seems to (mostly) work partially fix PowerShell pipeline output at least:

Oh, I' sorry - my fault. I searched in ...\GnuPG\bin instead of ...\gpg4win\bin

We use GetConsoleOutputCP but fallback to GetACP if the former fails. For some reasons one of the functions seems to return 437.

Given that you are already using libgcrypt 1.9, can you please try gnupg 2.3.4.

That is annoying enough that we should do a new release. I close this bug, though.

See T5758: scd: loop forever with reader_port, when open_pcsc_reader failed. Yes, the workaround is not to set reader-port.

Sorry for resurrecting the done task, but I got a message from @pmgdeb who noticed there is mismatch between parenthesis in the --with-fips-module-version help string. The attached patch fixes the issue and add proper help text.

I have just checked both the installation script, which still installs gpgme-json.exe and the gpg4win-4 installer downloaded from gpg4win.org gpgme-json.exe is properly installed under <instdir>\bin gpgme-json.exe and under bin_64

See T5758. The workaround is not to set a reader-port.

Downgraded the gnupg to 2.2.33 using this installer and I am now able to successfully open the Kleopatra GUI.

Should also note that once the GUI is opened, GnuPG's smartcard deamon (32 bit) transitions to Very high power usage and appears stuck there, consuming a full logical core's worth of CPU time.

And I'm testing following:

The "at first" change done.

At first, I think that we need to change the way how libgcrypt rejects non-approved cipher/md/mac/pk.

Backport done but diligent testing is required.

The debug log was from gpg and not from dirmngr and thus it is not helpful. I also guess that an older dirmngr was still running, because the LE bug has been fixed in 2.3.4.

Will go into 2.3.4.

In T5744#153233, @alexnadtoka wrote:

And --keyserver-options check-cert is removed from new gpg versions (((

Here is log in english

And --keyserver-options check-cert is removed from new gpg versions (((

@werner can you show me tutorial for proper bug submit? I think it is a bug and gpg client on Windows does not support valid LetsEncrypt certificates on keyserver. It does not work with any keys server . Tested few public keyservers as well. ((

We decided to notify the user if the keyserver doesn't return fingerprints. The fingerprints are needed by Kleopatra as unique identifier for keys. Trying to make key lookup work without fingerprints isn't useful.

Please see https://gnupg.org