Indeed, GnuPG's IPC uses TCP connections from 127.0.0.1 to 127.0.0.1 taking the destination port (and a cookie) from a file. We can't change that easily to the new Unix socket implementation Windows recently introduced. I hope there is a way to exclude localhost->localhost from congestion control.

This has always been the case. git blame shows for check_signatures_trust:

Here is a patch against master which normalizes line-endings when verifying text signatures over binary literal data packets

I don't see a bug here and any change in this domain disks a regression with existing data. BTW, the mode byte was not even part of the signed data before signature version 5.

My comment from a year ago still holds true; you may want to fix your testing framework and re-openig this bug iff you can show that there will be no regression with PGP 7 and later.

If you say so, i won't press this. I will just leave this ticket with an observation that even for someone who reads the source code this is not intelligible. At the top of gpgconf_list in g10/gpg.c, the comment says:

Installing language-pack-tr-base fixed the issue. Closing. Sorry for the noise.

In T7454#196228, @werner wrote:

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

LANGUAGE= LANG= LC_MESSAGES=de_DE gpg

Thus this should work. But it did only work when I used

LANGUAGE= LANG= LC_MESSAGES=de_DE.UTF8 gpg

Thus the whole thing is related to the configuration of locale.alias and on whether LANGUAGE is set in the environment (for me it is set to en_US:en

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

For this ticket, I reviewed the code around my SOS changes.
Because I'd like to focus the point of retaining binary representation when doing import->export,
I created another thicket: T7426

thanks for the clarification. i was not objecting to the workflow, i was trying to understand so that i can interact with the bug tracker appropriately. I was unaware of the difference between "milestones" and other project tags. I'll try to get that right in the future.

Please do not add milestone tags.

Reading the original bug report it is clear that this is not a gpg bug but a problem in the Python code. This should only be read as utf-8 if the NOTATION_FLAGS line indicated that this is human readable.

It seems too late to reject on import, given that people might already have such a secret key in their ~/.gnupg/private-keys-v1.d/ They might have had it for years without knowing it, because the failure is so intermittent. They might just think that they did something wrong, and when they try again it works. It would be great to be more robust than that.

In more than 25 years of OpenPGP we only had a few new implementations which got it wrong. I see no need to fix it here - maybe import could indeed reject such a key, though.

Maybe there's a 4th possible option that's better than the three i identified?

So i see a range of ways that any OpenPGP software could deal with this:

I can replicate that and it works if you disable the use of the CRT. Looking at the key:

pkey[0]: BC9E1CD66676208956B35357210C220508F9F883FE32F4D682CD36BFB4E8055938D4BA21C341D9F48527E420F951B80335B24DF6710F01C4364D554AF659FC35D322061B67CC2F303DC878076059E4F266CFAEF6AB7A29124E969B9C15B1FC2FBA0F0F90E6B059E36B5E3C9BEC4174162689108A1E0EF6D5DDEE61B6B48327A259746288A517B1D78A0E24F5EFF6E880FF39C0BEDDC464B66F787B559EC5487F248196C2CFB15730BD9695C48355DFB2839FA23D8A37FBD48C741F6BE19F9D48BF844C5147591E1E06803DA40BEA1186B3B39CDCBC0E7DAC9DACDBB60A20E56B7E6631E47A45989A256743FDD83C591CFD4110DEA1B04ADE91CCB575FB858C13
 pkey[1]: 010001
 skey[2]: 512FB977EB9872FECA8BDB96884A01A6AB2B7575D307B9ED4F55E777F2F55FBFFCBF4BF2D669D4D7F42CAC7C28F4ACC0ECEEF7B1D90E3D936850372352107F87E77E20A4D133C927F99FFD52277DEA17107BDA72A072AF950AB0B70023327E3B48D9CCB871237D3D6F6C9BA7FDB45AB46217E33FA01A8ED295795323E26505BC9471CAE4DDA94DBF4F35ED915B0CD025805DCA796EB6B208D8D3F63DBE52BC0045CF4CF9B128356359C7E55B661D7B9DCA57F8984095C5AD3FE4DBD19228B281D66609A154DD7E3EE940CFC66CC180DDC4DD00C45A52D5789286D89D49CA34E5F3C4E798D90955074DAE3D99F7F004CDFFBC9B8428E8EB603E240AE07BEE8D71
 skey[3]: F57D9F597750967DF272D9AC661DDC212D7C5CA4C6E91573A80756281351CDC3A2532B155D9251029F89A0A0807DF2BD177DC30FC6A847E07738B55606DF032ADAD8361E0AFEE9C0CF7D566793834977FAAE9C4B87132B94F665EFF463777CDE7EB89113FA3AAC194B6F2D30C40BE7C0DDE36A5855277C1E4D0204FC4C737BCB
 skey[4]: C4B135296B8F4390B953DDA84249FC8467CFF81FC715D1B5F3E01FCC8DC770813630AEA93982F2004705C4D272E07A10B1882AC5C09A45E88B14A1446B4C639B549420CE3BF90947E6E86503E426A8FDAC4C5CFC2809F5F0A1647ED5EE2457C054A40AA1F0666B28B2C970BE2093AE7B095A688B2D713CA8885826F23AFB37D9
 skey[5]: 0790A8E260C6CADC353FB3961D798EFD4F15F96752DA20B86841334C38861743DD7A1FEB2B750D0864F5901BE541B6C8FB63649B18FDC4A32A1233EF90872DCD35704A4B4063DB62752CF6A7FD00F086C6B1042A2B0CB6FB36B7D5269671DACF55242A838E60D514BA868354910CEB1C41FB9A43BF932B5036A6EFE35236FFC7

What is the current status of this issue?

It could have been discussed whether this makes sense. However, we can't change it anymore because it would change the behaviour. Consider a cron job which looks into a directory with keyids and imports them from a keyserver. It is totally fine if the script returns success if no keys are available.

In case if someone finds it through a search:

The solution seems to be a newer libccid version. If that is the case we may want to include the fix also in our own ccid driver.

Got this from my card vendor. Sonoma had a buggy CCID driver; compile one yourself and the bug's gone: https://forums.developer.apple.com/forums/thread/732091?answerId=768462022#768462022

For various reasons dirmngr requires and implements a full resolver and implements that. This way all DNS queries are passed through Tor. Thus this is a feature and not a bug. The error message could be better but we can only return what SOCKS tells us.

That's right: -K is merely a -k which prints only keys which have at least one secret key or a stub key (for smartcards) available.

Funny error description from macOS. Looks that there is no device - your PC/SC test programs confirms this. Thus I don't think this is a bug in scdaemon.

Sure it does not. That is the whole point of the loopback thing.

GnuPG is and can't be FIPS-140-3 compliant due to the way it is implemented. We may eventually employ the new hash-and-sign API of Libgcrypt to move into this direction but that has not yet been done. However, this also requires the use of the new indicator API and the, well, a RedHat kernel.

--openpgp means the current OpenPGP standard as implemented by GnuPG. This was important in the first few years of OpenPGP but not anymore today. The option --rfc4880 might be what you want. Please keep also in mind that the preference list declares what a concrete implementation supports and not necessary what's in an RFC.

Hi @werner,
I understand we should use --with-libksba-prefix, but it doesn't work:

That is not a bug but required for backward compatibility. See me/ksba.m4:

I never made a threat model. But definitely *any* cracker, should be out of my system, either from governmental agencies or from a kiddo in Russia.
I know that I have someone that is remote accessing my machine, since I got some tells. And that this cracker have used my Emacs text editor.

Smartcard PINs are different from passphrase for on-disk keys. Once a PIN is entered the smartcard is unlocked as long as it is powered up. In theory we could power down and power up the card to lock it. The question here is what is your threat model? If you have malware on your system it could simply brick your token or, more common, peek at your PIN.

I guess this is the first time such a key was reported. Printing diagnostics would be a bit of work because the code to compute th. expiration time is deep in gpg's guts.

The first signature is a direct key signature (class 0x1f) and this determines the expiration time. The usual case is to have the expiration time in the user id signatures. Our code does not allow to chnage the expiration time of direct key signature. This is because direct key signature are used by PGP and GnuPG only to add designated revokers. Gpg has no means to create a direct key signature like you have in your key.