3.1.0 is released and this issue is to our knowledge fixed.

( Apart from the part that was moved out to T3895 )

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

3.1.0 is released and this issue is to our knowledge fixed.

Thanks again. Good catch.
In Japanese 39 sounds like "Thank You!", that's indeed appropriate to your report. :-)

I think you are running in the infamous T3459 "As long as the decrypted content of a crypto mail is loaded a mail can't be moved" You have to unselect the mail and then move it without opening it. E.g. by right clicking it. I know this is horrible and it's a major problem but I don't see how we can fix it in our architecture. As we replace the mail content with the decrypted stuff we have to prevent "Write" Events by Outlook. For Move if you block a write event, the move fails. But we don't have any idea in our addon when a write comes from a move. I spent a lot of time on this and have not yet found a good solution. But I think the workaround is kinda ok.

The Bug is here that the Error is not shown properly. In the log:

When a command is invoked from Midnight Commander, pseudo tty is used.
You can confirm that by typing tty and see the output of the command after exiting from mc and again typing tty.

I am currently considering improvement of finalizer of libgcrypt, so, this matters.
Looking code, it would be better not to allocate and free the constant,
but use compile time constant data in .text section; Something like: const unsigned char ctr_null[DBRG_CTR_NULL_LEN].

Applied to STABLE-BRANCH-1-4, too.

Good catch. Thanks. Fixed in STABLE-BRANCH-2-2.

Apparently, your /lib/x86_64-linux-gnu/libgpg-error.so.0 is not the one you installed (I mean, libgpg-error version 1.27).
You need to install your new version of libgpg-error so that it is usable.
Please check your ldconfig or LD_LIBRARY_PATH, etc.

works just fine, thx!

I've opened T3895 for a permanent decryption / permanent removal of attachments. Maybe something for 3.2.0 ;-)

So I used a debugger to see if I could garner any additional info. Here's the log:

When an attachment of a crypto mail is removed it now leads to a warning.

In my tests it does work nicely now. We detect the "Send Again" state and correctly handle it. Sign / Encrypt is preselected depending on the state of the original mail. Even works with attachments.

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: