Here's fix for mode specific setkey clearing error code:
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Oct 23 2023
Jul 24 2023
Apr 23 2023
Apr 21 2023
There is still a buglet because in some modes the weak key error can be swallowed by other errors. A fix would be something like:
@jukivili Yes, please go ahead for both branches. Thank you.
Apr 20 2023
About error code. You need to use gcry_err_code(error_code) to get the GPG_ERR_WEAK_KEY value.
Apr 17 2023
Ok sorry, my bad, I have to use DES Keying option 2 to have 45 de ae ae e1 f4 6a 29, problem solved.
In T6451#169608, @gniibe wrote:Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.
Thank you for you responses! :)
I'll add documentation about GCRYCTL_SET_ALLOW_WEAK_KEY which was missing from be original commit.
tests/basic now actually fail because setkey not returning GPG_ERR_WEAK_KEY for weak keys with GCRYCTL_SET_ALLOW_WEAK_KEY.
That's right. With GCRYCTL_SET_ALLOW_WEAK_KEY, setkey still returns GPG_ERR_WEAK_KEY when weak key is detected. However, cipher handle can still be used as if setkey succeeded.
Reading the commit rC5beadf201312: Add gcry_cipher_ctl command to allow weak keys in testing use-cases,
The test code in basic.c assumes that it is an application responsibility to confirm&ignore GPG_ERR_WEAK_KEY error when using GCRYCTL_SET_ALLOW_WEAK_KEY.
Apr 16 2023
Thanks for the report. Fix is easy. I only wonder why you want to use a weak DES key.
Apr 14 2023
Apr 13 2023
Fixed in 1.10.2.
Apr 3 2023
Your quick support solve my problem, I am thanking you :)
Bye bye
I added a remark to the print function. Thanks for the suggestion.
You are right, w.y should be "00039E2C9AEC146C5799651C42691A3E35E291B6BC45FF079DDA3E70E709BF33".
Can you please share the expected result with us? Note that Libgcrypt strips leading zeroes except when it is required to keep the value positive.
Mar 8 2023
Thank you.
Applied to both (master and 1.10).
Mar 6 2023
Right, thanks for the review! Updated patches below.
Actually, the same issue is in the mac case, which I missed on first couple of reviews:
- enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos); + enum gcry_mac_algos alg = va_arg (arg_ptr, enum gcry_mac_algos);
Going through the code once more, there is one typo to be fixed:
+_gcry_fips_indicator_md (va_list arg_ptr) +{ + enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_cipher_algos);
should say
+_gcry_fips_indicator_md (va_list arg_ptr) +{ + enum gcry_md_algos alg = va_arg (arg_ptr, enum gcry_md_algos);
otherwise ack.
Mar 1 2023
We came to the same conclusion -- the SHAKE digests are not usable for sign/verify operations the way how it is implemented now. But it would be more clear if we would have explicit allow-list.
After consulting with our certs lab and studying the code I think SHAKE should not be a problem for now. All of the _gcry_digest_spec_shakeXXX seem to neither have an mdlen nor a read() function. pk_sign and pk_verify seem to both call md_read() which should fail because of the missing read function, kdf checks _gcry_md_get_algo_dlen() which should also disallow SHAKE.
Feb 27 2023
Good catch. A similar problem might arise with SHA384 according to section D.R which states
One potential pitfall here is that SHAKE-128 and SHAKE-256 must not be available for use in signature operations. That's because https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validation-program/documents/fips%20140-3/FIPS%20140-3%20IG.pdf section C.C disallows the use of SHAKE in higher-level algorithms:
These look good to me.
Right, we have received the same feedback from our cert lab but I haven't found time to update the bug yet. Here are the updated patches:
This marks GCRY_MD_CRC32, GCRY_MD_CRC24_RFC2440 and GCRY_MD_CRC32_RFC1510 as approved.
Feb 16 2023
May 27 2022
Aug 13 2021
Jun 2 2021
May 6 2021
FWIW, I think that it is a Bad Thing to use unreleased stuff from 1.8 for Debian packages. Only released versions sshould be used or patches we explicitly made to fix a bug. At the very least Andreas should have asked upstream whether this commit should be used for Sid.
Mar 1 2021
[2021-02-24] gnupg2 2.2.27-1 MIGRATED to testing (Debian testing watch)
Feb 10 2021
Jan 11 2021
Jul 15 2020
We can't do anything about it except for corner cases which we won't do right now. In case there will be an easy solution to help Debian please re-open this bug.
Jun 3 2019
I added the section in tools.texi. Closing.
May 20 2019
trigger what command? i'm pretty sure gpgconf --reload gpg-agent does not trigger updatestartuptty. And it should not do so, afaict -- if you think it should, i'd be interested in hearing the rationale for it.
Does gpgconf --reload gpg-agent trigger that command? that's the ExecReload setting in the systemd service unit I'm looking at.
May 19 2019
This doesn't sound systemd-specific to me, fwiw, though i don't understand how to reproduce the problem from the given description here.
Sep 11 2018
We assume that this has meanwhile been fixed.
Aug 29 2018
@elonsatoshi: Were you able to check this with 2.2.9 which has a fix for the resolver?
Aug 22 2018
This entry was created based on the conversation at #gnupg channel.
I can't reproduce keep hanging.
I confirmed that pinentry vanished (perhaps, because of timeout).
Aug 21 2018
gpg-agent has a pinentry caling timeout - doesn't that trigger?
In any case we agreed that Debian takes care of systemd support because that is not an upstream supported configuration.
Jul 3 2018
Backport done. To be released with 2.2.9.
Jun 21 2018
Done for master. Needs backport.
Jun 20 2018
We should include the man page then in texi format into tools.texi
Jun 5 2018
Please dee the commit for a description of this fix.
Jun 4 2018
I don't think this is an error in Debian. Debian Squeeze is packed with libgpg-error 1.26 in the latest stable release [1].
According to the list of changes, gpgrt.h is addes as an alias for gpg-error.h in 1.27 [2].
I think a quick (and correct) fix is to increase the NEED_GPG_ERROR_VERSION in configure.ac to at least 1.27 [3], so the build will fail nicely in the configure-step with a correct error.
May 11 2018
It seems that Debian does not install te required libgpg-error correctl.
May 10 2018
Nov 19 2017
You know... I think connman and DNS have something to do with this. Connman does some weird DNS thing. And it auto-generates /etc/resolv.conf to use localhost as the DNS server.
Nov 15 2017
This has been fixed a while ago my having dirmngr print a hint on the possible problem. gpg will then print a warning about a problem with the Tor configuration and with --verbose print the hint on solving this as well.
Nov 1 2017
OK, closed.
Oct 24 2017
Oct 20 2017
Given that we received no info after nearly two years, shouldn't we simply assume that this bug as been fixed?
Oct 14 2017
We need a way to delete a secret subkey.
No direct way. You can do this:
Ooops. you meant a subkey - let me check...
Sure: --delete-secret-and-public-key FINGERPRINT
Oct 13 2017
OK, sorry. Forgive me to ask here.. but is there a way how to remove both - the public and the private part? - and only of a specific subkey?
That is intended.
Aug 27 2017
Well, I'm able to reproduce this issue on Parabola. I was also get a different error when I turn off my vpn: `server indicated a failure```, but now I get the dns error again.
elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg gpg: DBG: chan_3 <- # Config: [none] gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.23 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/ gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr> gpg: error searching keyserver: Connection closed in DNS gpg: keyserver search failed: Connection closed in DNS gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks elonsatoshi@tyger ~> sudo rc-service openvpn stop [sudo] password for elonsatoshi: * WARNING: openvpn is already stopped elonsatoshi@tyger ~> pidof openvpn elonsatoshi@tyger ~> gpg -vvv --debug-level guru --search elonsatoshi@riseup.net gpg: using character set 'utf-8' gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache memstat trust hashing ipc clock lookup extprog gpg: DBG: [not enabled in the source] start gpg: DBG: chan_3 <- # Home: /home/elonsatoshi/.gnupg gpg: DBG: chan_3 <- # Config: [none] gpg: DBG: chan_3 <- OK Dirmngr 2.1.23 at your service gpg: DBG: connection to the dirmngr established gpg: DBG: chan_3 -> GETINFO version gpg: DBG: chan_3 <- D 2.1.23 gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KEYSERVER --clear hkps://pgp.mit.edu/ gpg: DBG: chan_3 <- OK gpg: DBG: chan_3 -> KS_SEARCH -- elonsatoshi@riseup.net gpg: DBG: chan_3 <- ERR 167772876 Connection closed in DNS <Dirmngr> gpg: error searching keyserver: Connection closed in DNS gpg: keyserver search failed: Connection closed in DNS gpg: DBG: chan_3 -> BYE gpg: DBG: [not enabled in the source] stop gpg: keydb: handles=0 locks=0 parse=0 get=0 gpg: build=0 update=0 insert=0 delete=0 gpg: reset=0 found=0 not=0 cache=0 not=0 gpg: kid_not_found_cache: count=0 peak=0 flushes=0 gpg: sig_cache: total=0 cached=0 good=0 bad=0 gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0 outmix=0 getlvl1=0/0 getlvl2=0/0 gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0 gpg: secmem usage: 0/32768 bytes in 0 blocks
Aug 14 2017
Aug 4 2017
Jul 19 2017
Implemented in da91d2106a17c796ddb066a34db92d33b21c81f7.
Jul 18 2017
Jul 17 2017
Jul 14 2017
Another reoccurring concern is lingering agents spawned in test suites. See, e.g. a discussion from this week: https://github.com/pazz/alot/pull/1081#issuecomment-315131053
Well, we always have to weigh the costs with the benefits. From the description of the task, the benefit was to satisfy "people [who] really don't like having idle processes lying around", which is not a strong motivation to take implementation and maintenance cost of any solution.
This is a disappointing resolution. There are many other reasons for having a daemon, which include keeping a sensitive piece of data in memory (and not on disk) for a limited period of time, while providing controlled access to it. This is exactly what gpg-agent does.
Jul 13 2017
Werner's comments indicate that this is expected behavior. Also, concerns were raised that this is difficult to implement correctly, and it is difficult to test. So, I am closing as wontfix.
The Debian report includes multiple workarounds for the quite unusual setup. So, I am closing here.
Jun 28 2017
Jun 26 2017
Fixed in 273964798592cd479c111f47e8ce46d5b1999d6a.
Jun 23 2017
Well, can you then please fix it?
Any update on this?
Jun 22 2017
@werner do you have any updates on this?
Jun 8 2017
I don't think this is a problem for GnuPG to fix. The user is running an OS that launches a version of gnome-keyring by default which doesn't fully-implement gpg-agent's functionality, and yet presents the gpg-agent interface. The user needs to either disable gnome-keyring, or upgrade to a version of the OS (or of gnome-keyring) that doesn't present the gpg-agent interface.
Jun 7 2017
this is not the place to report Debian bugs, nevertheless, I have assigned this to our resident Debian expert.