Sorry, no. The change is too large to back port it w/o risking a regression. As mentioned in T6481#170366 I don't consider this a bug. We are anyway working towards version 2.6 which will be the next LTS version.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
May 23 2024
May 22 2024
I think it would be cleaner to create a separate ticket for making gpg fetch the requested key from LDAP.
Any chance this could also be fixed in the 2.2.x series, where it seems to have been introduced in 2.2.42?
Although it is implemented in gnupg-2.2 we should add another feature: Iff this option is configured, gpg shall try to load the requested key from LDAP in the same manner as it does for a trusted-key.
This should not be configured in Kleopatra but an option to gpg because this is a core crypto functionality. Thus is now a gpg task.
this has been implemented since february 2023 in all gnupg versions
May 21 2024
great, thanks!
Assigning to Carl since he's working on this already.
Setting same priority as T6799.
We shouldn't change the name of the config file. The syntax is different from GnuPG's .conf files. Therefore it's better not to use the same file suffix.
correct, this only affects encryption
I assume you only implement this for encryption and not decryption. The latter should always be possible.
Right, thats my understanding from reading of the RFC that the padding should be strictly < 8B. We can reword though.
Well, but if the padding is indeed limited to 7 bytes the fix should be applied anyway.