Thank you, indeed it was my fault. After -enable-O-flag-munging it compiled (btw before that it spitted the same error in jitterentropy as the one referenced in the apple case, so maybe it's that?)

I don't think that it is a good idea to silence this warning. The pragma is esssential for proper random numbers and if clang hijacks a GCC's name space but implements something different it is better to have a warning than to fall into the pit full of dragons.

So, has this issue been solved?

In T5369#144864, @jukivili wrote:

That warning could be silenced by surrounding pragma with #ifdef __OPTIMIZE__ (with should be supported by GCC and Clang).

Thanks for your report.

A popular way is to export the subkey, delete the existing key pair, and then import the subkey back, so that the actual value of the master key will not appear in the key pair to protect the master key(The value of the master key will be backed up and stored in another safe place).
At this time, gpg -K will display the following for this key pair:

By " without a master key" do you mean a keypair where the private key for the primary key is missing?

Thanks. I push the fix of yours.

Done for all (libgcrypt (master, 1.9, and 1.8), libassuan, ntbtls, libksba, gpgme, gnupg (2.2 and 2.3).

Another solution to make life easier for gpgme users encountering this stuff would be if gpgme itself knows which uid is a DN and which is not, it could populate the gpgme_user_id_t.address field with content of the 1.2.840.113549.1.9.1 DN component. (or maybe gpgme_user_id_t.email, or both? as a user of gpgme, i don't really understand the difference between these fields)

fwiw, RFC 2253 is obsoleted by rfc 4514 -- which also doesn't have 1.2.840.113549.1.9.1 associated with "EMAIL", but does provide more detailed guidance for implementers of DN-to-string (and string-to-DN, to the extent that this is possible) conversions. Maybe the code should be updated to refer to the non-obsolete specification at least.

We translate only those OIDs from RFC-2253 to have a stable set of names in the libksba interface. If you need anything else, you need to do this yourself. For example gpgsm does this in in parse_dn_part, gpa has the code in format-dn.

I'm reporting this because the above message renders poorly in notmuch -- notmuch gets the user ID from gmime's g_mime_certificate_get_user_id, and gmime populates that field from the uids field of a gpgme_key_t object, and gpgme pulls uid information from gpgsm --with-colons.

Attached is a proposed patch.

Attached is an even worse PKCS7 blob, that should be validatable given reliance on ca.rsa.crt, but it will be rejected by gpgsm because the PKCS#7 bundle includes ca.rsa.cross2.crt in it.

OK, i have replicated this successfully with no ed25519 involved. here's the new intermediate cert:

Which NIST test suite are you referring to? It might not cover certificate pathfinding in the face of multiple cross-signed authorities.

@werner @ikloecker Any more thoughts / updates on this?

I do not have the time to analyse this in the context of our approved versions and to compare it to the NIST test suite. We also do not yet have support for ed25519 certificates.

Thank you. I checked what was missing and all looks good. But do not understand why the last gpgsplit xfree was not applied. We are leaving a block where this variable is dynamically allocated so even without error we need to free it.

thanks!

The error codes we use are a combination of code and location.

Thank you for your report.

The first two patch sets are now applied with the exception of
the gpgsplit fix; I did not applied that patch to add a free() in case of write errors.

In T5393#145098, @gniibe wrote:

Please note that *_error-from_syserror accesses system's errno which may be cleared by xfree.

Please read also the report T5442 which is basically the same.

Funny thing is that I can't replicate it anymore with the current version (2.2.18-beta77). I tested it on two machines and things just worked. One machine had just one reader and the other had several virtual readers in addition to the scr3500. After adding --reader-port for the latter it worked as well. I don't think I had a Windows update in the meantime.

Then let's get it in there. It's pretty easy to traverse a directory.

reading your report again: You clicked on a folder and expected that all encrypted files in this folder will be decrypted? That is unfortunately not supported.

I have the same message when i try to decrypt files larger than 1.5GB in size; i atached the report "gpgconf --show-version"

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

In T5436#146148, @ikloecker wrote:

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

Just got around to testing this on Linux, and I can confirm the same behavior: decryption PIN caching works on 2.2 and doesn't work on 2.3.

Due to tax issues, we can't accept a donation as return on service. However, we will fix bugs anyway if possible,

@znull You can also fix the detection issue by building with ./configure --disable-ccid-driver, in which case you won't need the disable-ccid setting anymore.

@ikloecker Sorry for not being clear, I was not aware different operations have different behaviors in regard to entering / caching the PIN.

It's not clear whether you are talking about PIN caching related to signing operations or decryption operations.

I just wanted to chime in that I've had exactly the same experience as @lbogdan: gnupg 2.3 stopped recognizing my yubikey entirely on MacOS until the T5415 workaround (disable-ccid). After that, pin caching was broken until I applied his patch to call-scd.c:548, which makes it work as before. Without these two changes the experience with gnupg 2.3 is degraded relative to 2.2.

So I did a bit more reading on smartcard PIN caching, and took a better look at the debug logging of gnupg 2.2, and learned that, indeed, the PIN is cached by the card and not by any one gnupg component.

Yes, I already linked to T5415, but that breaks YubiKey completely, and I fixed it with disable-ccid.

The pincache is actually not what you think it is. It is only used to allow switching between different application on a Yubikey which reqieres a new VERIFY command after switching back to the first application the card. What you feel as caching is the state of the card, which usually keeps its verification state until the card is powered down.

Frankly, I am pretty sure that the new base64 encoding of the fingerprint leads to less diligent comparison of the fingerprint by the user. I don't understand why they did not used a truncated hex output or zBase32 .

Thanks for using GPA. Unfortunately, I have to tell you that GPA development has been stopped and I can't say whether we will fix that bug any time soon. Please consider to switch to Kleopatra which is the standard key manager included in gpg4win.

On Windows, smartcard is also used by logon/logout and certificates handling. Those may be related.

(I disabled the account of this boor)

(I disabled this boor and restored the state)

I don't think that it is --pcsc-shared related; Andre reported that he noticed such a behaviour before we introduced this.

I wonder if PCSC_SHARE_SHARED is related or not.

Ah, great. Thanks!

You are welcome.

run-genkey is working fine in my test environment as well.

Technical commentary on smartcard operation and/or Windows is going to be over my head, so I can't help (just in case you're looking for anything from me). But always happy to drive-test another build. (I've still had no issues, personally, with the build above.) I'll assume you don't need me unless you link another binary build to test or tag me. Thanks again, all.

The problem is accesses to reader_table by
(1) scanning reader(s) to open new one
(2) closing reader

I'm testing D531: Keep holding READER_LOCK_TABLE and make clear distinction among close/releasing_PCSC_context/nullify_rdrname, but I'm not sure about the impact on Windows.