Sorry. I can't reproduce this. Neither with master nor with the 2.4 repo version.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Feb 19 2025
We don't have this exact action on windows, but the normal "Decrypt & Verify" action shows up for folders there (and doesn't work either).
All changes are pushed to master.
Pushed the changes by the commit rC2039d93289db: mpi: Add MPI helper modular exponentiation, Least Leak Intended.
Feb 18 2025
the reproducer is:
I don't think this is fixed. With this patch in place, if i import blocker.cert first, and then import distsigkey.gpg, it looks to me like i still can't verify signatures made from any of the GnuPG signing keys.
Can now be tested after the release of libassuan 3.0.2 (T6163)
Released with libassuan 3.0.2 (T7163)
Feb 17 2025
As I am delving a bit into cryptocurrencies and since i have a ledger security token and a bip32 24 word mnemonic now backed up as stamped metal i have stumbled accross this topic:
"Exclusive user" sounds a bit odd and could still be misinterpreted. A native speaker would probably say "Are you the sole user of this secret key?“ or (even better and shorter) "Are you the only user of this secret key?"
Feb 16 2025
Feb 15 2025
Feb 14 2025
Background of my "reminder" comment: we were discussing to establish a sane workflow for sharing keys. Which is quite commonly done e.g. for functional mail addresses, but usually people seem to share the whole secret key which is not advisable. We would want people to only share subkeys for that purpose.
It was the case that somebody gets a subkey for such an "offline" primary for the first time which I was thinking of.
Details should be the first action (since it's likely the most often used action by people who don't know about double-click). And I'd move the "destructive actions" to the bottom. And there are way to many separators.
In T7502#198141, @ebo wrote:Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?
Reminder: we have to keep in mind the workflow of the import of secret subkeys. Do we need different behavior conditional on "is primary key present" or not?
With my initial suggestions, modified by:
Use of mpi_cmp is now being fixed, by providing _gcry_mpih_cmp_lli function.
Along with that, we need to fix use of mpi_cmp_ui, since it's skips earlier depending its limbs.
diff --git a/cipher/dsa-common.c b/cipher/dsa-common.c index 170dce12..e010e182 100644 --- a/cipher/dsa-common.c +++ b/cipher/dsa-common.c @@ -25,6 +25,7 @@
Feb 13 2025
Just a note that i've tested this and --clearsign appears to be problematic for 2.4.7 as well as 2.2.40.
Another thing (should definitely go into a new ticket if we want to do something regarding this):