- User Since
- Mar 27 2017, 4:48 PM (221 w, 1 d)
So let's close this task.
That looks all fine.
With the next release you will get only a warning:
gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves
may give you some clues.
You are not using gpg4win with its included GnuPG 2.2 but some broken gpg version. The error message
"invalid size of lockfile" can only be emitted by the Unix version of GnuPG. Check for other installed gpg versions - there are sites which allows the download of for example a Cygwin version - these version can't work properly on Windows.
I did some test on Windows 10 using gnupg 2.2 with this patch and things work.
For testing ion Windows 10 you need to switch to "Legacy Console" and reboot.
Mon, Jun 21
Sorry for the expired certificate.
The thing is that I added a test for a new function which uses standard curves of Libgcrypt. But here we are again at the RedHat mess: They support the NIST curves but they removed support for Brainpool curves. Both are very similiar curves just different parameters. Brainpool is just in Europe out of fear that the NIST curves are rigged by the the NSA. Now, why RedHat removed Brainpool is probably just a legal dept thing who didn't have a clue. The tin foil hats probably see a different reason.
Supported curves should be listed by
gpg --list-config --with-colons curve
I am not sure about Fedora, but RedHat used to remove ECC support from Libgcrypt; GnuPG requires these curves. As long as you don't use ECC you things will work despite of this failed test. The test is new to check and does not anticipate a broken Libgcrypt.
- Worked on a A.E.T. Smartcard
Regression for keyserver search by mail address: T5497
Replicated and fixed. Thanks for the report.
Sun, Jun 20
Fri, Jun 18
ggp-agent has no support for U2F and it can't work with these key types. Given that Yubikeys also have proper keys (even eddsa) I doubt that we will implement support for ecdsa-sk OpenSSH feature any time soon,
Thu, Jun 17
That patch consists an ABI change. We might consider this for 1.10 but we can't do such a change in 1.9.
Please try the distributed binary version of gpgme from GnuPG or Gpg4win (which is usually a snapshot). As you might now, we don't support building on Windows - it may or may not work, we have no idea and don't suggest that.
Are you using Powershell or another non-standard shell? Which windows version are you using?
Thanks for the report. Will soon be fixed.
Wed, Jun 16
You should run your test program with GPGME_DEBUG set. This gives some insight. The code you posted is too sparse to actually see what you are doing or want to do or what is the bug. Maybe it is better to ask the gnupg-devel ML?
- the someflags thing will probably just be a reserved parameter
- If DATA is not NULL but an MD is set the sign function should fail
- Should ownership of MD be moved to the CTX?
CC does not offer such an option as the GPL does.
FWIW, there is also this newer patch: https://dev.gnupg.org/differential/diff/1476/
Tue, Jun 15
Our public key functions are stateless. For several reasons it would be good to have an option to keep some state (think pre-computations). Our gcry_ctx_t would be a perfect fit for this and it will allow us to join a pubkey function with for example a hash function.
Mon, Jun 14
Fix will eventually go into 2.2.29. If there is enough public demand we will do a new Windows installer earlier.
Sun, Jun 13
Check out https://gnupg.org
Sat, Jun 12
Thanks. Commited as rG755a5f1a0e3
Fri, Jun 11
Thu, Jun 10
The private key contains the public key. Thus there is no need to export the public key if you already got the secret key.