There is another customer request for this too.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 19 2024
Dec 12 2024
Dec 6 2024
Dec 5 2024
A workaround exists with the new option --ignore-crl-extensions.
Dec 3 2024
Dec 2 2024
Nov 29 2024
Done for 2.5.0.
Done in 2.5.0.
Fixed in 2.5.0.
Fixed in 2.5.0.
Nov 25 2024
Nov 11 2024
Nov 8 2024
Nov 5 2024
While reviewing this task I noticed that I wrote adding a -p option. This is non-sense, because -p is to preserve permissions at extract time; this is unrelated to the last modification time. Standard tar extract files and set the modification to the one given in the tarball - unless you use -m to use the current time. Thus this task is actually a bug and not a feature request. For backward compatibility this will be done only for gnupg26 for now.
Oct 29 2024
You should use gpg-agent's integrated ssh-agent. It is anyway much more convenient. I'll move this task to gnupg26, though.
Backported to 2.4 to go into 2.4.6
Oct 8 2024
Pushed the fix for exporting OpenPGP v5 key: rG57dce1ee62c2: common,gpg,scd,sm: Fix for Curve25519 OID supporting new and old.
Oct 4 2024
Oct 3 2024
The OID is used for fingerprint computation, which complicates things.
Oct 2 2024
Using the shorter OID for v5 is on purpose; thus we need to fix the export.
Oct 1 2024
Sep 25 2024
I don't think it makes sense to add such a feature/bug fix to the old versions.
Sep 24 2024
Please go ahead and apply to master. I'll take then care of backporting.
Done in GnuPG 2.5.0.
Sep 19 2024
This fix has the problem that for a signed message where the signing key is not available gpg emits the decryption_failed status line and prints "WARNING: encrypted message has been manipulated". This is because we use log_error to show that the signature could not be verified due to a missing key. The extra check we introduced with rG50e81ad38d2b lloked at the error counter and thus triggered the decryptio failed.
Sep 16 2024
Sep 12 2024
See new subtask T7290 for smartcards and the link entries mentioned above.
Sep 5 2024
Aug 28 2024
So we need a way to launch scdaemon via userv and make sure that the scdaemon user gives proper permissions to its socket file. gpg-agent also nees to check for a proper version of scdaemon and gpgme needs to be aware of this as well (if it want to directly connect to scdaemon).
Aug 21 2024
Aug 12 2024
Jul 4 2024
Jun 21 2024
Jun 19 2024
Jun 5 2024
Testing dirmngr by /home/gniibe/build/mingw-i686/gnupg/bin/gpg-connect-agent.exe --dirmngr 'loadswdb --force' /bye (configured distsigkey.gpg beforehand), I confirmed it works well now.
Jun 4 2024
Jun 3 2024
This is related to T6818
May 13 2024
May 12 2024
Yes, I think we should support this. Also X448. Thanks for the report and the samples.
Apr 24 2024
Apr 22 2024
Apr 15 2024
Apr 11 2024
Mar 19 2024
Note that this has also been ported to 2.4 and 2.2 and tested by looking at the status lines.
Mar 14 2024
Thanks for reporting this. Returning error codes to upper layers is not always easy because the original logic is that we have a global error counter to decide whether an operation succeeded. My fix to check the error code before emitting the DECRYPTION_OKAY status,