Yes thinking about this a bit more the checkbox is as redundant as any warning. The user interface clearly indicates that if you want to encrypt for others that you have to enter a name or email in this group. If the user does not notice that then a warning message or other explicit action will not help but make the user experience for most other users (requiring a click to check the checkbox) worse.

If I understand you correctly, you want to remove the checkbox before "Encrypt to others"?

Ah, I was not even thinking about the checkbox, yes you are both right. The encrypt to others should not be a checkbox but can be implicit regarding the selection of keys in the group "Encrypt to others."

I don't think a different foldername there would make a difference. When this is not updated it shows wrong information so I have changed this to T6525

If you only want to encrypt to one key you could do this without warning if you remove the check before "encrypt to others".

Maybe there just shouldn't be an "encrypt to others" checkbox. I mean, either you add keys of others or you don't. What's the point of the checkbox? Okay. I guess now you could encrypt to others but not to yourself. But that would still be possible. What wouldn't be possible is to add keys of others and then decide "Nah. I'll just encrypt to myself/with password."

We can do an added status line "Note: Only your key will be able to decrypt this file". But I don't think that will be very accessible.

works (at least for small directories)

High priority because I a fear that we will soon start to receive support questions related to this.

I guess kleo does a directory listing and then sorts hat listing the view Using the name by default but you can change this. Passing this list down to gpgtar is likely the original list as received from the OS. I also guess it will be easy to sort this but I'll give it a low priority.

Well, it Just Works(tm). You should make sure that a /run/user/NNNN direcory exists so GnuPG is able to create its subdir for the socket files.

I'm going to add selftest of EdDSA with test vectors from RFC 8032.

With the fix of T6523, make check goes all well (on Wine emulation and on Windows, for i686 and for x86_64).

Fixed in master.

I modified ffi.c, to have renamed process-spawn-io function doing I/O by C.

works:

Sorry to bump a discussion a few months after it has already died down, but with the deprecation and removal of init-based supervised launching of gpg-agent, what's the recommended approach now to auto-start it?

Calling assuan_release before kbx_client_data_release is the best (and we join the thread).

works

The current date should be avoided even if explicitly chosen, on the command line the earliest allowed date is tomorrow.

To align the default expiration time with the BSI approval and other related software we change this now to 3 years.

Would work better if every attention craving window would refer to the file resp certificate it addresses but that is covered by T6152

Works in kleopatra; tested with gpg4win-4.2.0-beta339.

Gpg4win doesn't include libexpat anymore (since it doesn't include gpa and pinentry-gtk anymore).

Gpg4win doesn't include libexpat anymore (since it doesn't include gpa and pinentry-gtk anymore).

I had a brief look at this. I don't think there's a way currently to convey "CRL Error" via a keylist result to gpgme. The --with-colons format would probably need to be extended.

I just thought, that we should still show "not certified" if the primary user ID is not certified because Kleopatra always displays the primary user ID (except in the Certificate Details).

tests/openpgp/import.scm hangs with 4096*4.