- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Jan 25 2024
Jan 24 2024
Hidden for Gpg4win-4.3.0-beta571, too
Possible fix for testing as patch: https://invent.kde.org/frameworks/kio/-/merge_requests/1540
Just a reminder, this is important for 384 bit keys (see T6379).
The state of the brain is:
Kleopatra behaves as intended (by me). Only subkeys meeting the following conditions are extended together with the primary key:
- skip revoked subkeys which would anyway be ignored by gpg;
- also skip subkeys without explicit expiration because they inherit the primary key's expiration;
- include all subkeys that are not yet expired or that expired around the same time as the primary key
These gpgsk files are standard private-keys-v1 files with an additional Backup-info line showing for example the keygrip.
There are no certificates in the file, thus we can either use gpg or gpgsm as driver.
No test environment in our QA dept.
Fixed in 2.4.4. Feel free to re-open if you still see problems.
No regression, assuming things work.
Hard to test without instrumenting the code.
Tested during development.
Tested for 2.4
@alexk and me tested this. The core functionality works.
Fixed in 2.4.4 and 2.2.43 - see above for affected versions.
Works for the two sample RSA cards. Ticket may eventually be re-opened if we run into problems with ECC cards.
Fixes are already in GnuPG 2.4.4 and can't be easily tested. Thus closing also for gnupg24
I wouldn't mind having the c++ and qt bindings in a separate library released at the same time as gpgme but with a cmake build system. It would simplify a lot in the craft build system as building the same repo with two different build system is not something that craft support very well...
Closing because we believe things are fixed and our test suite confirms that. Feel free to -reopen in case your own file does not import with 2.4.4.
The test file is now part of our test suite and passes.
We meanwhile have a lot of test cases in our test suite and we see no issue. Closing this bug; feel free to re-open if it is not fixed for your case in 2.4.4.
I did a couple of test on the command line which should be sufficient.
For existing files it does now do the same as when encrypting. Folders were already renamed automatically to avoid overwriting. This hasn't been changed.
We need to fix 2.2.42 too. This because we backported the responsible patch.
Move back to vsd33 Backlog because the changes may have to be merged to a (future) vsd33 branch.