Argh. I missed that. Probably because I searched for libgpg-error but I myself renamed the tag recently :-(.

Put the check in configure.

To clarify: We already use the getrandom system call if it is available. To map /dev/random to /dev/urandom you can create a file /etc/gcrypt/random.conf with this line:

Oops. I confused the ticket numbers rO34f6bb73882e: Implement send again for crypto mails. Would be the correct commit for this ticket.

Right, outlook.com is often problematic, although it might be a generic Exchange 2016 problem. Outlook.com and Exchange 2016 behave much the same.

For the situation where PINs are not factory setting, given the specification, I don't know how to achieve "to align all PWs and the KDF-DO with correct values"; It might depend on card's implementation.

You are right about the fact that multiple steps could result in unusable cards in case of power down before all commands have been issued. Nevertheless, in practice, these commands would involve very few treatments on the token (i.e. no cryptographic operation or heavy data transfer) and it should really not take long to complete the three steps (admin PIN update, user PIN update, KDF-DO update).

I'm not sure about that (Bug in Evolution), because I see ist only in E-Mails send by Evolution via Mircosoft (outlook.com) and not if Mails werden send by Evolution via Google (gmail.com).

In T3751#110422, @cipherpunks wrote:

What's in daily use for 15 yrs? GPGME? I thought GPGME was new,

Since the initial redacted data for those four keys is still accessible, I checked all of those keys manually and none of them are on the keyservers. Since the OP was connecting to the specified keyserver successfully prior to that failure, I believe this is the cause of the error and not another DNS vs. Dirmngr conflict.

This may be related to T3515: Gpg4win: Gpgconf used to open "windows" and slows down kleo startup since it depends on data from gpgconf.

Workaround is implemented in 2.2.6.

Fixed in 2.2.6.

My interpretation of the specification is different.
By requiring the condition of setting KDF-DO (it is only valid to setup KDF-DO when PINs are factory setting), Gnuk works well with current "kdf-setup".
If the procedure of setting KDF-DO includes multiple steps with KDF-DO update and PIN update, there is a risk of power down which results unusable card.

I've got an example mail. The problem is that the mail itself is "Content-Type: multipart/mixed; boundary="_003_DB4PR08MB01092D175DE8C1861B5D0BC197BF0DB4PR08MB0109eurp_"
"

dunno how to attach a patch here... trying to copy it verbatim

reproducer

--debug-wait 3

@werner here's the only output I get:

Please kill all existing dirmngr instances and don't run any programs which will trigger it to be started (e.g. Kleopatra). Then run in a _standard_ shell (cmd.exe):

I, too, have this problem. I have Windows 10 Pro 64-bit with BitDefender Total Security. My first reaction when this wasn't working was to disable all functions on BitDefender. That didn't help, so I ran dirmngr as admin in cmd (I despise PowerShell) without any luck. I created a non-admin user and ran it in there, again without luck. I've come up dry. No logs, no output, and no answers. Is there anything shy of downgrading dirmngr that will make this work? Has there been any progress as to figuring this out?

I'll go for a warning / error for now and see if I can fix the renumbering.

Thanks. I took these patches and simplified them. Not test tested, though,.

Note:
When we change the allocation, hmac256.c will not be standalone any more (as commented in the head of the file), and we will need to change the compile-command line to include libgpg-error.

I check this report again.
The test is single thread, IIUC.

Thanks for the fix! however, the fix only addresses the two flags we currently know about. I've pushed a branch T3880-fix that tries to implement the If the agent does not support the requested flags […] It must reply with a SSH_AGENT_FAILURE message part of the spec.

It is in 2.2.6

In fact, renumbering of attachments happens also by just viewing them repeatedly. This likely causes multiple copies somewhere, reducing disk space.

Thanks for the report and the spelling fixes :-)

Oh, you used a single dash and not a double dash in --armor. That is obviously the problem. As per Unix history all option characters may be combined unless they take an option arg; in that case the arg for the option may go directly after the option letter. We can't change that because lots of people and scripts use -rRECIPIENT.

Thanks for the report.

I see. Got it.

To be released with 2.26 next week

Right with (2) (1) will not occur if the key has been created with GnuPG. However, we have caches in the code path and further rogue software may create creates, interesting keys (tm). Thus I consider it better to explicitly request keys with cert flag set.

The patch has two parts; (1) detecting signature by incapable key and (2) limiting key with relevant capability.
I think that (1) is enough. I wonder with (2), (1) would not occur.

Forget my former comment. We only need to check subkeys becuase the primary key can always certify.
Here is a new revision of the patch:

I have another patch proposal to check the key usage. However, there is a catch-22. We get the usage flags from the key signatures and thus we can only check them after we checked the key signature.

The gpg20 tag was a typo.

Sorry, the patch above is completely wrong, since pk->pubkey_usage is not the right key to check.

If someone claims this is a kind of vulnerability, I think that what we need to fix is signature checking side:

Installed pinentry version is:

The bug is specific to 2.2, which may select available key on card. When such a selection, checking the PK->REQ_USAGE was missed.

Shouldn't this also be applied to STABLE-BRANCH-1-4?

This problem should be gone with Gpg4win-3.1.0-beta48. While I could not reproduce it I've tried to fix it and changed the hard error to a debug log in case something is unexpected here. I believe that this is safe.

I tried to reproduce this again, using S/MIME Mails, installing gpg4win 2.x etc. It did not crash for me :-/

Hmmm, needs to be investigated.

For secmem.c this is on purpose. For the others we should fix that.

Okay. We need to add a FAILURE status so that gpgme can better report this invocation error. Due to the double fork it won't be able to see the exit status. I assume you have the same problem in Enigmail.

Thanks. Indeed this should also use the x... wrappers. It is not severe because this value is only used as a fixed constant.
Thus we won't fix it in 1.8 but should do this 1.9.

Can you please provide the version of the tool "pinentry"

Normal prio as I don't think that this is a regression.

Thanks for trying out the beta. I was about to open an issue about this as someone in the forum reported the same thing. https://wald.intevation.org/forum/message.php?msg_id=5759

@dkg thanks for the link.

Yes, I meant the document. Please note that I am also one of users of the specification (for GnuPG, and for Gnuk Token). I am not defending, but try to explain the current situation.

I think that I located the bug and fixed. I wonder why Werner put gpg20 tag.

I was referring to this document:

You describe it as 'manual'. AFAIK, it's the specification for the functionality.
I have an experience implementing the functionality, following the specification.
And my own implementation does always return 512 bytes for RSA-4096. So, I could support your opinion.

Furthermore, I changed to have an explicit command: key-attr

I can verify the problem will be solved with 3.1.0, this can be closed.

I changed the interaction so that user can specify RSA or ECC, then when it's for ECC, specifying curve.

It looks like something wrong happened in scdaemon. Could you please try with following? .gnupg/scdaemon.conf