Here are the fixes:
diff --git a/common/init.c b/common/init.c index 073c5cd8a..dbdf40527 100644 --- a/common/init.c +++ b/common/init.c @@ -161,17 +161,6 @@ _init_common_subsystems (gpg_err_source_t errsource, int *argcp, char ***argvp) /* Try to auto set the character set. */ set_native_charset (NULL);
Call of WSAStartup in dirmngr/http.c is no problem, as we define HTTP_NO_WSASTARTUP.
This fix reveals the problem of: T4994: Windows: assuan_sock_init or WSAStartup by main/_init_common_subsystem
A reference might help:
https://blogs.itemis.com/en/openpgp-on-the-job-part-8-ssh-with-openpgp-and-yubikey
@mbrinkers : I think that it was fixed in GnuPG 2.2.21 by T4908: ECDH with AES-128 decryption failure when fully padded.
It was unfortunate that this bug report didn't work to solve problem, with malformed data and discussion went to unrelated thing.
So, where does "ssh-add" command come from? IIUC, it is from OpenSSH.
You mean running OpenSSH (and its tool ssh-add) on Windows, right?
It is not supported. PuTTY is supported.
Topics:
Last week:
This week:
Pushed fix to master and STABLE-BRANCH-2-2.
Thanks for your log.
(3) _gcry_ecc_os2ec in libgcrypt/mpi/ec.c should be modified to support parsing compressed representation.
While I see that it's not the matter of actual use case (but how gpg can be immune to fuzzing), code clean up would be good here.
Thanks for the patch.
I see your point in T4975: undefined-shift in block_filter.
You are right that we have a problem of possible overflow (which could be kicked by fuzzing) here.
(The actual impact would be small, though).
What kind of API should we offer?
(1) offering something like q@comp name for gcry_mpi_ec_get_mpi
But...
If the intended use case will be in create_request function in gpg/sm/certreqgen.c for subjectKeyIdentifier, the 'q' is already generated in the form of SEXP.
It is up to an application (gpgsm), to convert non-compressed point representation to compressed point representation, here.
Or this (don't allow anon keys for different usage):
diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c index 14cbdbb0f..b8d4059cd 100644 --- a/g10/pubkey-enc.c +++ b/g10/pubkey-enc.c @@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek) if (err) break;
Do you mean something like this?
It's in master (to be gnupg 2.3).
Enjoy.
Last week:
It seems that nl_langinfo(CODESET) returns US-ASCII on your system.
Yes, it will fix the problem on x32, I suppose.
If it's difficult for dpkg, for some reason for now, workaround for gpgme packaging is disabling pie hardening for x32 until pie will be its compiler default.
For gpgme, it is only test binaries which matter (pie or not), so, the impact (for x32) is minimum.
Some information of Qt5 about -fpic:
Debian's GCC build for PIE default: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules.defs#L1400
Here is my understanding. My point is it's not problem of gpgme. To fix it correctly, I think that dpkg should be fixed and it would be needed to fix Qt too.
I think that it is the problem of dpkg to override the compiler flag by the spec file. When compiler default is -fPIE, it works well. If not (for the case of x32), it fails.
In the past, hurd-i386 had same issue, but compiler default seems to be now -fPIE, thus no problem.
Thanks for your report.
Last week:
This week:
When I test it on Debian, disabling by,
Please get log of dirmngr, by putting
log-file /run/user/<YOURNUMBER-LIKE-1000>/dirmngr.log
I think the feature is not (yet) supported on Windows.
Please see: T3883: Add Win32-OpenSSH support to gpg-agent's ssh-agent
Pushed to master as rGa763bb2580b0: gpg,agent: Support Ed448 signing..
Update to [rGc94eea15d}.
Hash defaults to SHA512.
Last week:
This week:
D505:
(1) Has no (flags eddsa) in key in SEXP.
(2) Has no (flags eddsa) and no (hash-algo shake256) in data to be signed in SEXP.
(3) Has no (flags eddsa) and no (hash-algo shake256) in data to be verified in SEXP.
(4) Uses SHA256 for hashing of OpenPGP data
The changes just follow the existing practice of Ed25519, which does: