Ok then we can resolve this. Because I don't want to change the code there too much since it is about a plaintext leak which we cannot reliably reproduce so any change there we cannot really test if it brings up the plaintext leak again. And for users that have problems with the changing of the mail we can point them to the workaround.

Mh, let us concentrate in here on error messages. I was thinking "but what about disable-dirmngr in the settings" then all publish / refresh / receive actions should be disabled or invisible. So that is better something for a different task.

This issue might be a bit to general, some things like avoiding bad error messages are more important then a fully nice solution. A nice solution IMO would make all the "publish on keyserver" actions / checkboxes invisible in that case. If a restart is required when the setting changes that is ok in my book because the way we use "none" is intended that our entry level packages have "none" defined in the global config. Of course if a user then manually enters a value when none is set we would also need to bring up a message box stating that a restart is required for the change to take effect.

I tend to give this high priority since our SecOps state that the creation of non vs-nfd compliant keys is inhibited by our software by default (at least in the UI) I mean no one complained and it is not a regression but this should be fixed soonish. But this does not neccessarily mean before the next release.

Your tools don't use the chain validation model which is required for QES (at least according to German laws). A signature is still valid even if the certificate has been revoked. You need to consider the context and the time the certificate was revoked.

Is currently not enabled, sorry. Use git:// ot the mirror here at dev.gnupg.org. Note that we sign all our commits using a token and as such it is a stronger security prove than a just an arbitrary TLS connection.

Sorry, we have nothing do to with this pypi thing even if that file claims " The GnuPG hackers".

The debug/workaround option works: When the option is checked, opening the msg file will not change its date.

With VS-Desktop-3.1.90.246-Beta I can not import the secret part of the edward.tester@demo.gnupg.com.p12 Testkey (ECC brainpool).
I do not see any error message.

works: installed VS-Desktop-3.1.90.246-Beta with

Questions:

• What does "not certified" mean? Not certified by the user exporting the certificates (use case: I'm the "CA" for the exported group.)? Or not fully valid (i.e. not certified by a trusted certificate) (use case: I want to give some certificates to my co-workers and certification is centralized)?
• What about expired, revoked, or otherwise invalid certificates?

I have created T6766: Kleopatra: On export, inform user about uncertified user IDs for points 3 and 4 of T6469#174361.

Yes, it consists of libkleo DocAction actions which are invisible unless they find the document which they would open. I expect that I can somehow find the menu element and then hide it. But a patch against KXMLGui to hide empty submenus automatically might be a better use of our time. So I put this in the backlog and if someone wants to pick it up in some downtime feel free to fix this :)

The submenu is empty because the referenced actions don't exist outside of VSD builds, right?

it was decided to write the encrypted archive with ending .part and only rename it at the end. In this way the users can't think they have a valid encrypted archive

Thanks, what should I look out for? I don't think I can provide the .p12 directly because it is from a production provider that I do not have full access. I can provide the log and x509 public certificate again using the firefox generated one.

Needed changes in Kleopatra are tracked in T6761.

I am pretty sure that we have done everything in gnupg. Now if we only had a workboard for kleopatra.

Yes, apparently I confused uint8_t and unsigned char here because the former appears in Simon's comments. We also kept to the use of unsigned char* in our implementations (that is even part of the GNU coding guidelines if I remember correctly).

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.

Recent Mozilla again changed some things. Please see T6752. Can you please provide a sample in case this is not the same problem as in T6752?

Actually we never use uint8_t* because that is c99 and very uncommon except for some MCU projects. Instead we use unsigned char *. The use of void* is often used because this allows to pass arbitrary types to a function without requiring ugly and error-prone casting at the caller site.

The installation parameter for this is documented in our installation instructions. What is new with the next version is that for all files when you open them after installation of GnuPG VS-Desktop for the very first time you will be asked if Kleopatra should be used and have the option to make this permanent.

Since @ebo did not really know how to test I just checked that it is passed to gpg to resolve this issue.

You don't need a library but just one object file.

The issue mentioned in T6469#176392 is fixed.

OK, fine, however, in order to be able keep an overview of our tasks I would still keep track of them in our GitHub, where I can create a sub-issue from the list of tasks with one click. But we will post our comments and results here as well as far relevant for the purpose of documentation. I think most of the points Jussi raised are more or less clear to me anyway.

With respect to the function signatures, I see the following issues with the API you reference via the provided link:

@fse: Github is not an option here. We don't use it and thus everything relevant to Libgcrypt needs to be documented here and not at some external platform.

Some time ago, I have checked and hopefully fixed all usage of time_t in Kleopatra and GpgME to make sure we always use unsigned 32-bit integer arithmetic. Dates entered by the users are capped to some date in 2106 (a few days before the overflow date).

For length information, we can find that Simon's patch (let me call it v1) has length argument:
https://gitlab.com/jas/libgcrypt/-/commit/3af635afca052a9575912b257fe7518a58bfe810

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

Hi Jussi,

• There's many functions that use buffers on stack. Do those contain secrets? Should those buffers be wiped before returning from function (with wipememory())? For example, "mlkem_check_secret_key" has two buffers "shared_secret_1" and "shared_secret_2" which are not wiped.
• mlkem.c: mlkem_check_secret_key: "memcmp" is used to compare shared secrets. Should this use constant time comparison instead?
• mlkem-common.c: _gcry_mlkem_mlkem_shake256_rkprf:
  • _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close.
• mlkem-symmetric.c: _gcry_mlkem_shake256_prf:
  • _gcry_md_hash_buffers_extract can be used here instead of _gcry_md_open&write&extract&close. Temporary buffer usage can be avoided by passing input buffers through two IOV to _gcry_md_hash_buffers_extract.

Few comments on the patches.