Considering the concrete use case(s), it is more rational to support listing by capability.

Many cards have some printed information and I consider them important to avoid testing one by one all the cards from my pocket.
This I am really in favor of beeing asked to insert the respective card. The new text format private key files make it much easier to maintain this info

In T1287#94619, @werner wrote:

2.1 has the option --unwrap to just this.

My analysis is that it's not a race condition but... it's about secure memory.
It is true that we have a race condition between putting an entry to cache after pinentry interaction _and_ next examining cache to invoke pinentry. But for this test case, the gpg process of unlock the key (and cache the passphrase) is finished before running the run-threaded command.

I am currently investigating the issue known as CVE-2019-14855 for Debian's LTS version Debian 8 "Jessie" and even Debian 7 "Wheezy".

Regression due to a faulty backport. Fixed in repo; patch is F1052802
Thanks for reporting.

Okay, I can replicate that on gnupg 2.2; it works correct on master.

I am not sure what you want you are going. I see is a verify command using an unknown file or number of files without knowing its content (using globbing (*-SOMETHING) is not a good idea). Some signature is verified okay but it is not known whether the key is trustworthy. You export a ke and then you do a verify on the key - this can't work because a key-file is not a signature.

No bug.

See T4760.

This is a bug tracker and not a general help line. You are better off asking on the gnupg-uisers mailing list.

See also D475.

Without --expert my proposal for full-gen-key would be:

That is due to the mitigation for CVE-2019-14855. I need to see how to find a more specific mitigation.

Same here, having YubiKeys and on-disk ssh keys from several computers, it is a bit a pain not to know which key is actually used. Any chances to get at least an update via manual editing of the comment?

I've also noticed this issue on windows when trying to symlink %APPDATA%\gnupg to $HOME/.gnupg under msys32.

BTW: I have the problem that I want to know the keys of all cards. "getinfo card_list" along with --demand can be used for this. gpg-card works this way. It does not work if plug in addtional cards becuase card_list shows only the cards for which a SERIALNO command has been used. A new feature to scan the buses for all readers and cards would be quite useful.

Still there are two places where we use "SCD serialno --demand <SERIALNO>". One is g10/skclist.c where we list available keys, another is the funciton card_key_available in agent/command-ssh.c .

By the change of rG9f39e0167d06: agent: Fix ask_for_card to allow a key on multiple cards., the SERIALNO in the stub is just an auxiliary information, not identifying the card. Now, it is the keygrip for key to identify/select the card.

I did too many things at once.
I'm going to divide up into pieces.

Thanks. Fixed in stanble and master.

And also this is excellent point.

The agent is an important part of gnupg and it does not make sense to single out cases when it might not be needed. I can't see any harm from having an agent running. In fact, one of th netxt versions will add yet another daemon which will then be needed in all cases.

Thanks, @gniibe. From reading this patch (i haven't tested it), it looks like it would avoid most unnecessary agent launches (and agent communication) in the (b) case, which is a win over the status quo.

Fixed in master.

This part of code is questionable. It always comes fp!=NULL, so the part should be removed.
If fp==NULL, use of tmpfile is quite questionable because a user can't know where the trace output goes.
I'm going to remove that part.

If it makes sense to warn a user for someone's preference when keys are imported,
here is a patch:

Please see my explanation on gnupg-devel about why the trailing NUL is a source of pain and difficulty for would-be adopters.

Appending a nul byte is fail-safe programming and helps in debugging. It is on purpose and shall not be removed.

Except w32_system function, it's done.

I've just broken out my changes into two commits, one that makes gpg and gpgsm more robust. That should be applicable without any risk.

I've just posted rGb84feb0c82eb to the dkg-fix-T4652 branch, which solves the failure problems by making agent_pkdecrypt and gpgsm_agent_pkdecrypt more robust.

fwiw, this patch appears to cause gpgsm to fail its test suite:

I've just pushed rG1ae16838660a to the dkg-fix-T4652 branch (i just adjusted it the commit message to include the GnuPG-bug-id)

Hi everyone,

It responds somehow, but the content has invalid data of (bChainParameter=0x04):

2019-07-05 09:36:41 scdaemon[71407] DBG: chan_17 -> S LOGIN-DATA aheinecke
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 21
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 4
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 21
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bChainParameter ...: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 82 00 82
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 22
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 4
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 22
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bChainParameter ...: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 82 00 82
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: PC_to_RDR_XfrBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 9
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 23
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bBWI ..............: 0x04
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   wLevelParameter ...: 0x0000
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0010]  00 40 05 00 CA 00
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   [0016]  6E 00 E1
2019-07-05 09:36:46 scdaemon[71407] DBG: ccid-driver: usb_bulk_read error: LIBUSB_ERROR_TIMEOUT
2019-07-05 09:36:46 scdaemon[71407] ccid_transceive failed: (0x1000a)
2019-07-05 09:36:46 scdaemon[71407] apdu_send_simple(1) failed: card I/O error

After the cancellation, the card reader seems being screwed up:

It is canceled:

2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: RDR_to_PC_DataBlock:
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   dwLength ..........: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSlot .............: 0
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bSeq ..............: 19
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bStatus ...........: 64
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver:   bError ............: 239
2019-07-05 09:36:41 scdaemon[71407] DBG: ccid-driver: CCID command failed: PIN cancelled
2019-07-05 09:36:41 scdaemon[71407] DBG: dismiss pinpad entry prompt
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> INQUIRE DISMISSPINPADPROMPT
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 <- END
2019-07-05 09:36:41 scdaemon[71407] verify CHV2 failed: Invalid response
2019-07-05 09:36:41 scdaemon[71407] operation decipher result: Invalid response
2019-07-05 09:36:41 scdaemon[71407] app_decipher failed: Invalid response
2019-07-05 09:36:41 scdaemon[71407] DBG: chan_7 -> ERR 100663372 Invalid response <SCD>

It was rG07250279e7ec: * keyedit.c (keyedit_menu): Invisible alias "passwd" as "password". in 2004, which set default to rfc2440-text behavior.
And in 2007, the commit rGb550330067b6: * gpg.c (main): Disable --rfc2440-text and --force-v3-sigs by default. changed the default to no-rfc2440-text.

Thanks, fixed in master.

I disabled the dependency rules for the figures (it's only enabled for maintainers).

We should put it of the agenda od the Brussesl summit in 3 weeks. I have a few ideas what we can do in gpg.

I pushed my change of rGc51a5685554a: scd: ccid-driver: Initial getting ATR more robustly..
With TTXS, scdaemon correctly recovers from the error.

When the computer is going to suspend, the scdaemon receives a message from USB layer as the interrupt transfer is shutting down, then scdaemon considers it's removal of device/card.
But in case of suspend (and the device does not support USB suspend), USB port is kept with the power.
So, it keeps running actually.

Here are results of my experiment with Intel NUC computer (which supports S4 (and S3)).

No. I intentionally select: Not-backporting this feature.
The feature is added for Yubikey, in the specification.
Use of the feature by Data-Object is not that so useful.

I think we should not backport this to 2.2 - okay?

Works for me! :-)

Not sending the user id packet, is just a bad idea because that user id exists and from my understanding they are sending the self-signatures anyway. They should not try to argue with the GDPR here, that is privacy theater. The key itself is a personal data and due to technical reasons this data is required. What they can do is to accept only user ids which carry just only mail address and no comments or name. posteo.de for example requires this for years and the WKD drafts has a feature to support this.

Just want to weigh in here to say this would be incredibly useful given the shift to the new keyserver model. See T4604 for more context.