Thanks for the offer. However, the core developers are using tokens for more than a decade meanwhile. We even make our own tokens ;-).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Dec 12 2021
Dec 11 2021
Dec 10 2021
Hi jukivili,
The first is a warning and the other error codes are exactly what we want.
Adding comments, fixing "const" qualifier, I pushed the change.
Thank you, applied.
Dec 9 2021
It turned out that the new *.inp files are not part of the release tarball, which makes the tests from generated tarball fail. The attached patch should fix this issue.
A patch created:
Thank you, applied.
Dec 8 2021
Sorry for the noise. There were couple of other places which I missed initially and which are covered in the v2 patch which follows:
It turns out together with rCe96980022e5e some tests are failing in FIPS mode. The attached patch should handle the failures.
GnuPG 2.2 does:
- In g10/sign.c:do_sign, it keeps leading zeros for Ed25519 signature, as opaque MPI
- In g10/build-packet.c:do_signature which calls gpg_mpi_write to output the (opaque) MPI, leading zeros are removed.
Let me explain concretely.
While testing I noticed that another requirement was to hide the advanced button. I have added this myself.
Excuse me NIBE san. What if any action do you expect me to take on this matter?
__outer
Reading compressed point format has been done.
If writing support is needed, please open another task.
This new API is not for FIPS directly (any more), as we introduced pk_hash_sign/verify for FIPS.
Pushed the backport.
I have been convinced disabling DSA makes more sense.
Done.
(Actually, it's not in the tarball.)
Dec 7 2021
Hi jukivili,
I ran some basic tests and it did show the errors. I am in the process investigating what went wrong. In the meantime, i also included test result that I have used in my testing from bench-slope. In this test, I captured the message with 272 bytes buffer from the original libgcrypt repo and my optimized repo. Note that the bulk version of my code do 8x unrolling and the rest will do 16 bytes. So the first 2 128 bytes ran thru gcry_ppc_aes_gcm_encrypt and the rest of the 16 bytes thru gcm_ctr_encrypt (cipher-gcm.c).
Hmm,
$ gpg --with-colons --list-config curve cfg:curve:cv25519;ed25519;cv448;ed448;nistp256;nistp384;nistp521;brainpoolP256r1;brainpoolP384r1;brainpoolP512r1;secp256k1
How would Kleopatra know that cv* is for encryption, ed* is for signing, and all other curves are for both uses? Or are the cv/ed prefixes a (de facto) standard?
You may run
For GnuPG 2.2, it's better to be conservative (least change of behavior, if any).
We have tests in gniibe/new-pk-api, which can be backported.
- t-dsa
- t-ecdsa
- t-rsa-pss
- t-rsa-15
Thank you, applied.
The patch has been applied.