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.

Well I have looked at this ticket and posted a comment. We should talk about if there is anything left to do or not. I suspect that the gpg side is done and I should open one (or probably better several) ticket(s) for the kleopatra side.

Ah nevermind missing icons were related because I also removed the highcolor icons for testing.

works now with VS-Desktop-3.1.90.246-Beta

Mmh, on further checking I notice that some icons are missing though. Need to investigate where they went. I basically just took the inst-breeze.nsi file, and removed all the NSIS things and did a sort -u on it to create the list of icons.

So, I smashed this all together. The icon subset and the cross compile patch, and my time for first startup was 5 seconds then once with procmon enabled 7 seconds and now with a reduced set of icons I am down to Kleopatra to 1.7seconds. The icon subset is just 1.4mb. With all the icons we would have installed for Okular and Kleopatra. I don't have enough time to clean this up today to push it but this looks very good.
Although I am thinking to add a way to kicontheme maybe as a global variable to provide the name for the resource file so that we can properly switch between breeze-dark and breeze.

In T6702#176858, @aheinecke wrote:

We should probably also check KMail though. There might be a similar fix needed although there I am unsure if the old keyresolver does not do a crl check when a certificate is selected.

Fixed.

The error message in Kleo is now (with VS-Desktop-3.1.90.246-Beta) "Broken pipe". But in the linked error protocol you can find the gpg error message "no space left on device". So I would find this message acceptable.

As what I see is similar as what Andre saw, I'll describe it here. Please check if this is relevant.
After the above mentioned Ticket was resolved, I tried the exact same encryption in Kleopatra on the same Test-VM.

Ok. Both notepad and file encryption now again produce errors as expected. So the new override would just be a new feature and no longer a regression.

And yes in gpgsm.conf both the extensions are also marked with ignore-cert-extension.

While remembering this I added to our standard.conf (and for testing first to my local conf):

The issue should be fixed, i.e.

• groups containing only encryption-capable certificates (i.e. they have an encryption subkey) are expanded
• certificates which cannot be used for encryption because they (or just the encryption subkeys) are revoked or expired or otherwise invalid are marked with the error marker
• the OK button is disabled if any invalid encryption certificate is selected

works!

For testing with file encryption and notepad you can use this chain which is valid but does not provide a valid CRL for us

We just realized that similar to what we had in GpgOL ( https://dev.gnupg.org/T6701 ) that AlwaysTrust is used by default. And this will now result in the behavior which I also mentioned in our meeting that without question it encrypts to any S/MIME certificate. Without any warning that it is not VS-NfD compliant to do so.
This must be fixed because otherwise we show an operation as VS-NfD compliant, e.g. to encrypt to a certificate with a broken CRL. Which is not VS-NfD compliant because the CRL check was not done.