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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 16 2023
May 27 2022
Aug 13 2021
Jun 2 2021
May 6 2021
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.
Hi there,
May 24 2017
May 23 2017
May 17 2017
May 4 2017
Apr 10 2017
This is fixed in bf8b5e9042b3d86d419b2ac1987a9298c9d21500.
Apr 7 2017
I confirmed that it's 64-bit big-endian.
I wrote a patch for testing. D421: padding is needed for 64-bit big endian
If s390x is big-endian, we need padding at the start of the cell structure. So that the _flag can be compatible to the vector element.
I'll see on the porterbox myself, too.
Apr 6 2017
I just merged the current git head over on zelenka, which includes b83903f59ec5d49ac579f263da70ebc8dc3645b5, and managed to still get the same segfaults.
@gniibe good catch! I'll fix that and we'll see if that improves things.
IIUC, cells are used for a place for vector elements.
I'm afraid what happens for memory space not used for vector elements.
fwiw, this remains a problem on 2.1.20: https://buildd.debian.org/status/fetch.php?pkg=gnupg2&arch=s390x&ver=2.1.20-1&stamp=1491409561&raw=0
Apr 3 2017
Sure:
Fix is in 2.1.20
Mar 31 2017
Mar 30 2017
Mar 28 2017
Yes, print *a was correct. Could you please do
print *sc->load_stack[sc->file_i]->curr_line
there?
I've now pulled from the current master head
(caf00915532e6e8e509738962964edcd14fb0654), rebuilt on zelenka with -O0 -g, and
triggered the error again, causing a core file to be dumped.
I copied gpgscm-gdb.py into tests/gpgscm/ , added it to add-auto-load-safe-path
in ~/.gdbinit, and then ran "gdb -c tests/gpgscm/core tests/gpgscm/gpgscm" and
tried to print a, as requested. here's what i got:
0 (sid_s390x-dchroot)dkg@zelenka:~/src/gnupg2/gnupg2/build$ echo
add-auto-load-safe-path
/home/dkg/src/gnupg2/gnupg2/build/tests/gpgscm/gpgscm-gdb.py > /home/dkg/.gdbinit
0 (sid_s390x-dchroot)dkg@zelenka:~/src/gnupg2/gnupg2/build$ gdb -c
tests/gpgscm/core ./tests/gpgscm/gpgscm
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later < GPL license >
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "s390x-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
< GDB Bugs >.
Find the GDB manual and other documentation resources online at:
< GDB Documentation >.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./tests/gpgscm/gpgscm...done.
[New LWP 7145]
Core was generated by `./gpgscm ../../../tests/gpgscm/t-child.scm'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000002aae4ecf748 in is_vector (p=0x4634508) at
../../../tests/gpgscm/scheme.c:220
220 INTERFACE INLINE int is_vector(pointer p) { return (type(p)==T_VECTOR); }
(gdb) bt
#0 0x000002aae4ecf748 in is_vector (p=0x4634508) at
../../../tests/gpgscm/scheme.c:220
#1 0x000002aae4ed3470 in vector_elem (vec=0x4634508, ielem=7) at
../../../tests/gpgscm/scheme.c:1349
#2 0x000002aae4ed975e in tailstack_flatten (sc=0x2ab046296f0,
tailstack=0x4634508, i=8, n=7, acc=0x2ab04629838) at
../../../tests/gpgscm/scheme.c:3117
#3 0x000002aae4ed99d4 in callstack_flatten (sc=0x2ab046296f0, i=8, n=7,
acc=0x2ab04629838) at ../../../tests/gpgscm/scheme.c:3155
#4 0x000002aae4ed9af0 in history_flatten (sc=0x2ab046296f0) at
../../../tests/gpgscm/scheme.c:3173
#5 0x000002aae4ed8488 in _Error_1 (sc=0x2ab046296f0, s=0x2aae4efe634 "eval:
unbound variable:", a=0x2ab0462bdd8) at ../../../tests/gpgscm/scheme.c:2777
#6 0x000002aae4eda162 in opexe_0 (sc=0x2ab046296f0, op=OP_EVAL) at
../../../tests/gpgscm/scheme.c:3298
#7 0x000002aae4ee3ef0 in Eval_Cycle (sc=0x2ab046296f0, op=OP_T0LVL) at
../../../tests/gpgscm/scheme.c:5358
#8 0x000002aae4ee5384 in scheme_load_named_file (sc=0x2ab046296f0,
fin=0x2ab04684f90, filename=0x2ab04684d80 "../../../tests/gpgscm/init.scm") at
../../../tests/gpgscm/scheme.c:5748
#9 0x000002aae4ec1ec6 in load (sc=0x2ab046296f0, file_name=0x2aae4efc7d4
"init.scm", lookup_in_cwd=0, lookup_in_path=1) at ../../../tests/gpgscm/main.c:180
#10 0x000002aae4ec22cc in main (argc=0, argv=0x3ffffe44e48) at
../../../tests/gpgscm/main.c:266
(gdb) up 5
#5 0x000002aae4ed8488 in _Error_1 (sc=0x2ab046296f0, s=0x2aae4efe634 "eval:
unbound variable:", a=0x2ab0462bdd8) at ../../../tests/gpgscm/scheme.c:2777
2777 history = history_flatten(sc);
(gdb) print a
$1 = (pointer) 0x2ab0462bdd8
(gdb) print *a
$2 = define-macro
(gdb)
maybe i'm doing something wrong? i'll ask and see whether i can give out an
account on the porterbox for you, justus.
Mar 27 2017
I have looked into this. I installed Debian on an s390 emulator (hercules), but
have been unable to reproduce the problem there, maybe due to the emulation (it
is quite slow on my system, and the gpgscm interpreter seems especially slow,
maybe because of the challenge of doing branch prediction on interpreters).
Your stack trace suggests a memory corruption early during the initialization
("init.scm", the standard library, is being loaded), we see an error being
generated due to an unbound variable (i.e. the environment hash table is
corrupted / does not perform as expected). Then we see a segfault while the
history buffer is flattened into a list for the error message (i.e. hints at a
corruption).
Unfortunately, memory corruption bugs are very hard to detect in gpgscm due to
its use of a custom memory allocator. The allocator allocates large segments
using malloc and hands out cells from that pool as necessary. However, memory
is never freed, so tools like valgrind can not be used to detect use-after-free,
or even most out-of-bounds accesses.
I have been working on the low-level allocator last week trying to make it more
debuggable and memory errors more detectable, e.g. by moving parts of the
interpreter into readonly sections.
As Werner said, a stack trace with less optimizations would be helpful. Also,
is the problem always the same if it happens? If so, it would be interesting to
know what kind of variable is unbound (for that, inspect the 'a' parameter of
'_Error_1' [I'm attaching a pretty-printer for gdb, with that, do 'print a']).
Access to the porter box would be helpful as well.