Page MenuHome GnuPG
Feed Advanced Search

Mar 28 2017

dkg added a project to T3022: Please relax the spamfilter on this bug tracker: Bug Report.
Mar 28 2017, 2:55 PM · Bug Report
dkg added a comment to T3014: Intermittent crashes in gpgscm on s390x.

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 28 2017, 2:34 PM · Debian, Bug Report, gnupg
dkg placed T3014: Intermittent crashes in gpgscm on s390x up for grabs.
Mar 28 2017, 2:34 PM · Debian, Bug Report, gnupg

Mar 22 2017

dkg added a comment to T3014: Intermittent crashes in gpgscm on s390x.

Roundup won't let me include the details, but i will say that from a git bisect,
i discovered that the first commit that has this behavior is
49e2ae65e892f93be7f87cfaae3392b50a99e4b1 ("gpgscm: Use a compact vector
representation.")

The crashes that happen are segfaults.

Mar 22 2017, 10:54 PM · Debian, Bug Report, gnupg
dkg added projects to T3014: Intermittent crashes in gpgscm on s390x: gnupg, Bug Report, Debian.
Mar 22 2017, 10:52 PM · Debian, Bug Report, gnupg
dkg set Version to 2.1.19 on T3014: Intermittent crashes in gpgscm on s390x.
Mar 22 2017, 10:52 PM · Debian, Bug Report, gnupg
dkg set External Link to https://bugs.debian.org/858400 on T3014: Intermittent crashes in gpgscm on s390x.
Mar 22 2017, 10:52 PM · Debian, Bug Report, gnupg

Mar 14 2017

dkg added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.

This bug report simply asks to solve the generic problem of GNUPGHOME being
larger than sun_path. Justus's proposed mechanism is only one way of solving
that problem.

Another proposed mechanism is what i originally proposed in T2964 (dkg on Feb 17 2017, 01:52 AM / Roundup), which
*does* address remote filesystems and re-mounted filesystems.

I don't undertstand the critique about the code not yet being mature. Code
doesn't become mature by not being written, it needs to be written first and
then tested in order to become mature.

Lastly, i think if we expect that /run/user/$(id -u)/ is a "simple dependency"
for building other software, we need to make that expectation explicit someplace
reasonable (e.g. doc/HACKING or something similar)

Mar 14 2017, 4:39 AM · Stalled, scd, gpgagent, Bug Report, gnupg, dirmngr

Mar 1 2017

dkg added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.

Justus, thanks for this work, it's great!. If we can solve the problem by doing
more clever socket(7) manipulation, that would be a big win.

How do you propose dealing with the getsockname() variations? or should we just
forbid the use of getsockname() entirely in the gnupg codebase?

Mar 1 2017, 7:24 PM · Stalled, scd, gpgagent, Bug Report, gnupg, dirmngr
dkg added a comment to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path.

Yes, notmuch decided that they needed to workaround the situation anyway,
because they're in an environment that doesn't create the standard per-user
rundir. That doesn't seem like a great argument that gpg should also fail in
environments where the standard per-user rundir is available. I can demonstrate
a number of environments where gpg or its daemons will fail, but i don't think
any of them justify forcing gpg or its daemons to *also* fail when those
environments aren't present.

In answer to your nitpick, here is evidence that gpg's daemons cannot create
their sockets when the GNUPGHOME is too long:

1 dkg@alice:~$ mkdir -m 0700
/home/dkg/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long
0 dkg@alice:~$
GNUPGHOME=/home/dkg/tmp/very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-very-long
gpgconf --launch dirmngr
gpgconf: error running '/usr/bin/gpg-connect-agent': exit status 1
gpgconf: error running '/usr/bin/gpg-connect-agent --dirmngr NOP': General error
1 dkg@alice:~$

Mar 1 2017, 2:02 AM · Stalled, scd, gpgagent, Bug Report, gnupg, dirmngr

Feb 22 2017

dkg added projects to T2973: --export-options export-minimal does not work with --export-secret-keys: gnupg, Bug Report.
Feb 22 2017, 11:47 PM · Bug Report, gnupg
dkg set Version to 2.1.18 on T2973: --export-options export-minimal does not work with --export-secret-keys.
Feb 22 2017, 11:47 PM · Bug Report, gnupg

Feb 21 2017

dkg added a comment to T2968: gpg --search: Connection closed in DNS.

Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?

Feb 21 2017, 4:43 PM · Info Needed, gnupg (gpg22), Bug Report, Debian, Keyserver, dirmngr

Feb 17 2017

dkg added a comment to T2942: gpg needs to offer a way to list OpenPGP packets without consuming them.

Thanks, i've pushed this back to python-gnupg folks, and they've accepted it:

https://bitbucket.org/vinay.sajip/python-gnupg/commits/d0375e034da3efa6fbda713cb4bde0fbb6d3b158

so i think we can consider this issue resolved, at least from 2.1.14 and onward,
where import-show was introduced.

Feb 17 2017, 10:13 PM · Bug Report, gnupg
dkg closed T2942: gpg needs to offer a way to list OpenPGP packets without consuming them as Resolved.
Feb 17 2017, 10:13 PM · Bug Report, gnupg
dkg set External Link to https://bugs.debian.org/855419 on T2966: "LC_ALL=pl_PL.UTF-8 gpg --gen-key" fails during confirmation.
Feb 17 2017, 9:01 PM · Restricted Project, Debian, Bug Report, gnupg
dkg set Version to 2.1.18 on T2966: "LC_ALL=pl_PL.UTF-8 gpg --gen-key" fails during confirmation.
Feb 17 2017, 9:01 PM · Restricted Project, Debian, Bug Report, gnupg
dkg added projects to T2966: "LC_ALL=pl_PL.UTF-8 gpg --gen-key" fails during confirmation: gnupg, Bug Report, Debian.
Feb 17 2017, 9:01 PM · Restricted Project, Debian, Bug Report, gnupg
dkg added a comment to T2928: stop fetching PTR records entirely.

Thanks for these fixes! I'm not sure i understand why ptr lookups are needed
for keyserver --hosttable. Can we drop those too?

Feb 17 2017, 3:48 AM · Debian, Bug Report, gnupg, dirmngr
dkg added projects to T2964: dirmngr and gpg-agent should work automatically even when GNUPGHOME is larger than sun_path: dirmngr, gnupg, Bug Report.
Feb 17 2017, 1:52 AM · Stalled, scd, gpgagent, Bug Report, gnupg, dirmngr

Feb 16 2017

dkg added a comment to T2933: gnupg-2.1.18 fails to read a Yubikey Neo that gnupg-2.1.17 reads fine.

This sounds like issues we were seeing in debian, which i believe have been
fixed in git already.

we're shipping the following two patches in debian against 2.1.18:

https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/0028-scd-Backport-two-fixes-from-master.patch/
https://sources.debian.net/src/gnupg2/2.1.18-6/debian/patches/0029-scd-Fix-use-case-of-PC-SC.patch/

Feb 16 2017, 11:00 PM · Bug Report, gnupg

Feb 14 2017

dkg added a comment to T2959: with --tofu-default-policy=ask, Assertion "conflict_set" in get_trust failed (../../g10/tofu.c:2787).

I note that even if i drop the "--trust-model tofu+pgp" and subsequently invoke
just "gpg --tofu-default-policy ask --fingerprint" i get the same crash.

however, if i just execute that in a fresh homedir without ever having set
"--trust-model tofu+pgp" i don't get a crash. so there is some sort of state
being set up that is then tickling the assertion later.

Feb 14 2017, 4:40 PM · Restricted Project, Debian, Bug Report, gnupg
dkg set External Link to https://bugs.debian.org/854829 on T2959: with --tofu-default-policy=ask, Assertion "conflict_set" in get_trust failed (../../g10/tofu.c:2787).
Feb 14 2017, 4:21 PM · Restricted Project, Debian, Bug Report, gnupg
dkg set Version to 2.1.18 on T2959: with --tofu-default-policy=ask, Assertion "conflict_set" in get_trust failed (../../g10/tofu.c:2787).
Feb 14 2017, 4:21 PM · Restricted Project, Debian, Bug Report, gnupg
dkg added a comment to T2959: with --tofu-default-policy=ask, Assertion "conflict_set" in get_trust failed (../../g10/tofu.c:2787).

Feb 14 2017, 4:21 PM · Restricted Project, Debian, Bug Report, gnupg
dkg added projects to T2959: with --tofu-default-policy=ask, Assertion "conflict_set" in get_trust failed (../../g10/tofu.c:2787): gnupg, Bug Report, Debian.
Feb 14 2017, 4:21 PM · Restricted Project, Debian, Bug Report, gnupg
dkg set Version to 2.1.18 on T2958: Extend --unwrap to also remove a compression layer..
Feb 14 2017, 3:57 PM · gnupg24, gnupg (gpg23), Feature Request
dkg added projects to T2958: Extend --unwrap to also remove a compression layer.: Feature Request, gnupg.
Feb 14 2017, 3:57 PM · gnupg24, gnupg (gpg23), Feature Request
dkg added projects to T2957: gpg --export-ssh-key does not work for primary keys marked as authentication-capable: gnupg, Bug Report.
Feb 14 2017, 2:48 AM · Bug Report, gnupg, Restricted Project
dkg set Version to 2.1.18 on T2957: gpg --export-ssh-key does not work for primary keys marked as authentication-capable.
Feb 14 2017, 2:48 AM · Bug Report, Restricted Project, gnupg

Feb 13 2017

dkg added a comment to T2943: gpg should issue a warning when it is run without a command.

I'll just note that the only programmatic unattended uses i've seen have been
*not* decryption. they're attempts to list a keyring. So switching to
decrypted mode there will provide the same amount of breakage as requiring an
explicit command, but without the benefit of requiring explicit intent.

Any variation in behavior between automated and "attended" use is a debugging
pain point that actually seems to create work in the rest of the ecosystem. The
more GnuPG can keep its rules and behavior simple to understand, the better.

Feb 13 2017, 7:48 PM · Bug Report, gnupg
dkg added a comment to T2948: libdns lookups fails when nssswitch has no "dns" section.

right, the configuration is not an error, but a different way of handling the
DNS lookups.

just to clarify: this change means that dirmngr will continue to use libdns in
the event of finding no understood directives in nsswitch.conf. it is *not* the
equivalent of falling back to standard-resolver. right? If that's correct,
then i agree that an extra warning is probably too much noise.

Feb 13 2017, 7:39 PM · Restricted Project, Bug Report, gnupg, dirmngr
dkg added a comment to T2943: gpg should issue a warning when it is run without a command.

Right, agreed -- there is no way to get to the "improved --list-packets" without
using the dubious approach of not specifying a command at all.

I agree that a hard failure when --batch is given without an explicit command
would be reasonable (though that means we will be effectively breaking
python-gnupg and others like it, which do try to use it). I'm not sure i
understand the reasoning behind a hard failure for --with-colons without an
explicit command.

Feb 13 2017, 5:52 PM · Bug Report, gnupg
dkg added a comment to T2948: libdns lookups fails when nssswitch has no "dns" section.

looks reasonable to me, though i haven't tried it myself (my nsswitch.conf
doesn't have the initial property reported).

Perhaps there should be an additional explicit log message for the
!ld.resolv_conf->lookup[0] case since dirmngr is falling back?

Feb 13 2017, 5:26 PM · Restricted Project, Bug Report, gnupg, dirmngr

Feb 12 2017

dkg added a comment to T2034: pinentry emacs features need documentation.

So i'm left a little confused here about what the resolution is. neal added
documentation, but ueno suggested it was wrong and contributed a patch for it.
However, that patch hasn't been applied.

Some additional questions about pinentry-emacs and INSIDE_EMACS that came up in
discussion over on https://bugs.debian.org/854797:

    What's the best way to debug a problem when emacs pinentry
    isn't working?  do we look at gpg?  gpg-agent?  pinentry? emacs itself?
    all of those places?  What happens when the user has two separate
    instances of emacs running?  What if there's an instance of emacs
    running and someone uses tramp to connect to a remote ssh server, and
    gpg-agent is providing the ssh-agent interface?  What if someone uses
    ssh from *outside* of emacs and it talks to a gpg-agent that was
    auto-launched from within an emacs session?  What about when there's an
    instance of emacs running in a graphical session on a machine where the
    same user is also logged into the machine via ssh, and they're using a
    different graphical session?  how does pinentry-emacs interact with
    emacs --daemon and multiple emacsclient instances?

Another few questions:

Why does emacs use /tmp/emacs$UID for the ephemeral socket instead of

/run/user/$UID ?

If OPTION allow-pinentry-emacs is set, but the emacs process isn't

repsonsive (or nothing is listening at all) should pinentry do a second layer of
fallback, e.g. to curses?

Feb 12 2017, 8:36 PM · Bug Report, pinentry

Feb 8 2017

dkg added a comment to T2928: stop fetching PTR records entirely.

The unnecessary PTR lookup is causing problems for other people too, over on
https://bugs.debian.org/854359

Feb 8 2017, 11:33 PM · Debian, Bug Report, gnupg, dirmngr
dkg set External Link to https://bugs.debian.org/854359 on T2928: stop fetching PTR records entirely.
Feb 8 2017, 11:33 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2946: gpg-agent should be able to terminate when all its state expires.

I agree about that race condition being an important thing to consider, but i
think it's orthogonal to whether the process is self-terminating.

That is: we need to consider that race condition even in the case of deliberate
shutdown too, right?

Do we have a test case that involves two concurrent processes, one that tries to
stop the agent, and the other that tries to access it?

Feb 8 2017, 4:01 PM · gnupg, Debian, gpgagent, Feature Request
dkg added projects to T2948: libdns lookups fails when nssswitch has no "dns" section: dirmngr, gnupg, Bug Report.
Feb 8 2017, 12:03 AM · Restricted Project, Bug Report, gnupg, dirmngr
dkg set Version to 2.1.18 on T2948: libdns lookups fails when nssswitch has no "dns" section.
Feb 8 2017, 12:03 AM · Restricted Project, Bug Report, gnupg, dirmngr

Feb 6 2017

dkg set Version to 2.1.18 on T2946: gpg-agent should be able to terminate when all its state expires.
Feb 6 2017, 9:19 PM · gnupg, Debian, gpgagent, Feature Request
dkg added projects to T2946: gpg-agent should be able to terminate when all its state expires: Feature Request, gpgagent, Debian, gnupg.
Feb 6 2017, 9:19 PM · gnupg, Debian, gpgagent, Feature Request
dkg added a comment to T2945: gpg should explicitly set output file permissions during decryption.

Sorry: to clarify my previous remark: i don't think gpg should change from its
current behavior during *encryption*. I do think it should be more constrained
in its output during *decryption*.

Feb 6 2017, 7:24 PM · Feature Request, gnupg
dkg added a comment to T2945: gpg should explicitly set output file permissions during decryption.

I don't think it's a problem that the files created during encryption simply
obey the umask.

I do think that when gpg creates sensitive data, though, it should limit the
mode of its output to the mode of its input (filtered by the umask, of course)

if the mode of the input is INMODE, and the umask is UMASK, during decryption,
when gpg creates an output file, it should set the mode to (INMODE & ~UMASK).

(if gpg is decrypting and sending output to stdout, perhaps it wants to try
fchmod (1, INMODE & ~UMASK) as well?)

Feb 6 2017, 7:23 PM · Feature Request, gnupg
dkg set Version to 2.1.18 on T2944: gpgconf --change-option should not print a warning when the relevant conf file does not exist.
Feb 6 2017, 6:54 PM · Restricted Project, Bug Report, gnupg
dkg added projects to T2944: gpgconf --change-option should not print a warning when the relevant conf file does not exist: gnupg, Bug Report.
Feb 6 2017, 6:54 PM · Restricted Project, Bug Report, gnupg
dkg set Version to 2.1.18 on T2943: gpg should issue a warning when it is run without a command.
Feb 6 2017, 6:49 PM · Bug Report, gnupg
dkg added projects to T2943: gpg should issue a warning when it is run without a command: gnupg, Bug Report.
Feb 6 2017, 6:49 PM · Bug Report, gnupg
dkg added projects to T2942: gpg needs to offer a way to list OpenPGP packets without consuming them: gnupg, Bug Report.
Feb 6 2017, 6:38 PM · Bug Report, gnupg
dkg set Version to 2.1.18 on T2942: gpg needs to offer a way to list OpenPGP packets without consuming them.
Feb 6 2017, 6:38 PM · Bug Report, gnupg
dkg added a comment to T1982: pinentry-qt should fallback to curses if $DISPLAY is set but unavailable.

anyone skilled in qt want to fix this outstanding issue?

Feb 6 2017, 9:26 AM · pinentry, Feature Request

Feb 5 2017

dkg added a comment to T1967: GnuPG should select a key for signing without trying to use missing subkeys.

I've tested Simon's patch against 2.1.18, and i think it's the right thing. I
posted it to the mailing list in git-format-patch form here:

https://lists.gnupg.org/pipermail/gnupg-devel/2017-February/032547.html

Feb 5 2017, 10:51 PM · gnupg (gpg22), Feature Request
dkg added projects to T2941: outbound file descriptors (status-fd, attribute-fd, logger-fd) should fail if descriptors is not initially open: gnupg, Bug Report.
Feb 5 2017, 9:17 PM · Bug Report, gnupg
dkg set Version to 2.1.18 on T2941: outbound file descriptors (status-fd, attribute-fd, logger-fd) should fail if descriptors is not initially open.
Feb 5 2017, 9:17 PM · Bug Report, gnupg
dkg added a comment to T1967: GnuPG should select a key for signing without trying to use missing subkeys.

Any progress on this?

A reproducer, even without smartcards (please ensure that GNUPGHOME is
explicitly set):

ARGS="--pinentry-mode loopback --passphrase abc123"
ARGS="$ARGS --batch --with-colons --with-keygrip --status-fd 3"

gpg $ARGS --quick-gen test@example.org rsa cert 3>genkey.status
FPR=$(awk '/KEY_CREATED/{ print $4 }' < genkey.status)
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-1.status
sleep 5
gpg $ARGS --quick-add-key 0x$FPR rsa sign 3>addkey-2.status
GRIP=$(gpg $ARGS --list-keys | grep ^grp: | cut -f10 -d: | tail -n1)
mv $GNUPGHOME/private-keys-v1.d/$GRIP.,bak
gpg-connect-agent killagent /bye
echo test | gpg $ARGS -u "$FPR" --clear-sign

Feb 5 2017, 8:42 PM · gnupg (gpg22), Feature Request
dkg added a comment to T2022: dutch localizations for GnuPG.

This was included in 2.0.30, but somehow was missing from the 2.1.x branch.
I've included it in master as of 8a9d4b55b09d04482b46055f0a60f01b86738df3

Feb 5 2017, 6:54 PM · gnupg, gnupg (gpg20), gnupg (gpg14), Feature Request, i18n
dkg changed Version from 2.0.28, 1.4.19 to 2.0.28, 1.4.19, 2.1.18 on T2022: dutch localizations for GnuPG.
Feb 5 2017, 6:54 PM · gnupg, gnupg (gpg20), gnupg (gpg14), Feature Request, i18n
dkg closed T2022: dutch localizations for GnuPG as Resolved.
Feb 5 2017, 6:54 PM · gnupg, gnupg (gpg20), gnupg (gpg14), Feature Request, i18n
dkg set Version to 2.1.18 on T2940: dirmngr fails for hkps when http-proxy is in use.
Feb 5 2017, 9:35 AM · Feature Request, gnupg (gpg22), Debian, gnupg, dirmngr
dkg set External Link to https://bugs.debian.org/818802 on T2940: dirmngr fails for hkps when http-proxy is in use.
Feb 5 2017, 9:35 AM · Feature Request, gnupg (gpg22), Debian, gnupg, dirmngr
dkg added projects to T2940: dirmngr fails for hkps when http-proxy is in use: dirmngr, gnupg, Bug Report, Debian.
Feb 5 2017, 9:35 AM · Feature Request, gnupg (gpg22), Debian, gnupg, dirmngr
dkg changed External Link from 846175@bugs.debian.org to https://bugs.debian.org/846175 on T2856: Can't ssh-add a key w/o a passphrase.
Feb 5 2017, 9:18 AM · Debian, Bug Report, gnupg, ssh
dkg added a comment to T2856: Can't ssh-add a key w/o a passphrase.

Any thoughts or progress on this?

Feb 5 2017, 9:18 AM · Debian, Bug Report, gnupg, ssh

Feb 4 2017

dkg added a comment to T2932: gpgv error messages are confusing.

the reason "no public key" is confusing is because gpgv already knows that there
can be no public key. So the message that the naive user needs to see in this
case is "no keyring available".

If there is at least one keyring available, then saying something like "no
public key found in keyrings X and Y and Z" is reasonable. but if there are no
keyrings at all, the message should just be something like "no keyring found to
validate signature against".

Feb 4 2017, 8:01 AM · Bug Report, gnupg, gpgv
dkg added a comment to T2935: use-tor should have a third possible value, "if available".

Thanks for this work (and sorry to have just blindly/wrongly assumed that
--no-use-tor already existed without checking it).

On modern debian systems, the default tor daemon will always be listening on
unix domain socket /run/tor/socks. So a simple attempt to connect to that
socket should be sufficient -- it should fail immediately if the socket isn't
present or if no one is listening on it.

This seems cheap and fast enough to be able to do it on every query to me,
rather than introducing additional runtime state to dirmngr. just try to
connect, and if it doesn't work, fall back to a normal connection (you'd want to
do that anyway in case the tor daemon goes away after dirmngr had been launched).

Feb 4 2017, 2:56 AM · gnupg (gpg22), In Progress, Feature Request, dirmngr

Jan 31 2017

dkg added projects to T2935: use-tor should have a third possible value, "if available": dirmngr, Feature Request, gnupg.
Jan 31 2017, 9:49 PM · gnupg (gpg22), In Progress, Feature Request, dirmngr
dkg set Version to 2.1.18 on T2935: use-tor should have a third possible value, "if available".
Jan 31 2017, 9:49 PM · gnupg (gpg22), In Progress, Feature Request, dirmngr

Jan 25 2017

dkg added a comment to T2930: search for keys by e-mail address behaves differently when key is in pubring.gpg vs. pubring.kbx.

thanks for the quick fix, Justus. I can confirm that this fixes the problem for me.

Jan 25 2017, 9:01 PM · Bug Report, gnupg
dkg reopened T2930: search for keys by e-mail address behaves differently when key is in pubring.gpg vs. pubring.kbx as "Open".
Jan 25 2017, 9:01 PM · Bug Report, gnupg
dkg added projects to T2932: gpgv error messages are confusing: gpgv, gnupg, Bug Report.
Jan 25 2017, 12:19 AM · Bug Report, gnupg, gpgv
dkg set Version to 2.1.18 on T2932: gpgv error messages are confusing.
Jan 25 2017, 12:19 AM · Bug Report, gnupg, gpgv

Jan 24 2017

dkg added a comment to T2928: stop fetching PTR records entirely.

for cases (1), (2), and (3) it sounds like you don't need the PTR at all. right?

For your case (4), i think we should reject hkps via literal IP addresses. It's
not a real-world use case, and if you want to test/experiment with hkps as a
developer, you should have at least the capacity to edit /etc/hosts (or whatever
your system's equivalent is). Anyway, trying to support this case for the
purposes of debugging doesn't make sense if support for this case is the cause
of the bugs in the first place ;)

re: duplicate hosts: I live in a part of the world where dual-stack
connectivity is sketchy at best. And, when connecting to things over Tor, it's
possible that connections to IPv4 hosts will have a different failure rate than
IPv6 connections.
So unless you already know that the host itself is down, why would you avoid
trying the other routes you have to it?

Look at it another way: when trying to reach host X, you discover that X has two
IP addresses, A and B. You try to reach A and it's not available. Isn't it
better to try B instead, rather than to avoid trying B at all just because A was
unreachable?

In a pool scenario, you might want to try to cluster addresses together by
perceived identity so that you can try an entirely different host first, rather
than a different address for the same host who happens to be in the pool twice.
But that strikes me as a very narrow optimization, certainly something that'd
only be worth implementing after we've squeezed the last bit of performance out
of other parts of the code (parallel connections, "happy eyeballs", etc).
Definitely not something to bother with at the outset. So i'd say drop that
optimization for simplicity's sake.

So the simplest approach is:

a) know the configured name of the keysserver
b) resolve it to a set of addresses
c) try to connect to those addresses, using the configured name of the server
for SNI and HTTP Host:

This is all that's needed for cases (1) and (3), and it could also be used in
case (2) if you see (b) as a two-stage resolution process (name→SRV→A/AAAA),
discarding the intermediate names from the SRV. Given that some people may
access the pool via case (1), and servers in the pool won't be able to
distinguish between how they were selected (SRV vs. A/AAAA), they'll still
accept the connections.

If you decide the additional complexity is worthwhile for tracking the
intermediate names in the SRV records, you can always propagate the intermediate
names wherever you like locally without changing the "simplest" algorithm.

If you really want to use the names from the SRV in collecting, then the
algorithm should change to:

a) know the configured name of the keyserver
b) resolve it to a set of intermediate names
c) resolve the intermediate names to a set of addresses
d) try to connect to those addresses, using the intermediate name of the server
for SNI and HTTP host.

But still, no PTR records are needed.

Jan 24 2017, 5:12 PM · Debian, Bug Report, gnupg, dirmngr
dkg added projects to T2931: Provide automated way to set "primary" flag on a specific User ID in a cert: Feature Request, gpgme.
Jan 24 2017, 4:48 PM · gpgme, Feature Request
dkg added projects to T2930: search for keys by e-mail address behaves differently when key is in pubring.gpg vs. pubring.kbx: gnupg, Bug Report.
Jan 24 2017, 4:20 PM · Bug Report, gnupg
dkg set Version to 2.1.18 on T2930: search for keys by e-mail address behaves differently when key is in pubring.gpg vs. pubring.kbx.
Jan 24 2017, 4:20 PM · Bug Report, gnupg
dkg changed Version from 2.1.17 to 2.1.18 on T2928: stop fetching PTR records entirely.
Jan 24 2017, 5:39 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2928: stop fetching PTR records entirely.

Here's a concrete example of how using PTR records gets things mixed up.

keyserver.stack.nl offers keyserver service on port 443.

It has an A record at 131.155.141.70.

But the ptr is to mud.stack.nl:

70.141.155.131.in-addr.arpa. 69674 IN PTR mud.stack.nl.

and the https SNI and HTTP Host: directives provide an entirely different
website depending on whether you access it with:

  https://mud.stack.nl/

or

  https://keyserver.stack.nl/

If you access it as https://hkps.pool.sks-keyservers.net/, you get the
"keyserver" view. But if you access it by the name in the PTR record
("mud.stack.nl") then you get the mud view (and a 404 on any /pks URLs)

Even more troubling is that dirmngr successfully connects to mud.stack.nl and
does the query, even though it is configured to only talk to
hkps.pool.sks-keyservers.net

This suggests that anyone able to spoof a PTR record to me can get my dirmngr to
send my potentially-sensitive keyserver queries to an entirely different webserver.

Jan 24 2017, 5:37 AM · Debian, Bug Report, gnupg, dirmngr

Jan 23 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

I've moved the discussion about the need for PTR over to
T2928

In this ticket, let's focus on what happens when Tor has the NoIPv6Traffic flag
set. How should dirmngr respond in that case?

I think if it gets a "permission denied" from its tor socket (or from any proxy)
when it's trying to connect to a host, it should treat that host as dead and
move to try next one. If dirmngr knows that it is using tor, and it knows that
the address it is trying is also IPv6, it could also log a message about the
IPv6Traffic flag.

does that seem like the right set of changes needed?

if you add NoIPv6Traffic to your torrc, and restart tor, can you replicate the
problem?

Jan 23 2017, 10:29 PM · Debian, Bug Report, gnupg, dirmngr
dkg renamed T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set from dimrngr over tor fails repeatedly on IPv6 records to dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.
Jan 23 2017, 10:29 PM · Debian, Bug Report, gnupg, dirmngr
dkg set Version to 2.1.17 on T2928: stop fetching PTR records entirely.
Jan 23 2017, 10:25 PM · Debian, Bug Report, gnupg, dirmngr
dkg added projects to T2928: stop fetching PTR records entirely: dirmngr, gnupg, Bug Report, Debian.
Jan 23 2017, 10:25 PM · Debian, Bug Report, gnupg, dirmngr

Jan 18 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

here's the example run from my modified reproducer script that focuses on
oteiza.siccegge.de:

gpg: keybox '/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 6 oteiza.siccegge.de v6=[2a01:4a0:59:1000:223:9eff:fe00:100f]
OK
2017-01-18 03:19:00 dirmngr[30881] listening on socket
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/S.dirmngr'
2017-01-18 03:19:00 dirmngr[30882.0] permanently loaded certificates: 0
2017-01-18 03:19:00 dirmngr[30882.0] runtime cached certificates: 0
2017-01-18 03:19:00 dirmngr[30882.0] failed to open cache dir file
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/crls.d/DIR.txt': No such file or directory
2017-01-18 03:19:00 dirmngr[30882.0] creating directory
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/crls.d'
2017-01-18 03:19:00 dirmngr[30882.0] new cache dir file
'/home/dkg/tmp/tmp.XgzSpI4Oy0/gpg/crls.d/DIR.txt' created
2017-01-18 03:19:01 dirmngr[30882.6] handler for fd 6 started
2017-01-18 03:19:01 dirmngr[30882.6] connection from process 30879 (1000:1000)
2017-01-18 03:19:01 dirmngr[30882.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 03:19:02 dirmngr[30882.6] DBG: dns:
getsrv(_pgpkey-http._tcp.oteiza.siccegge.de) -> 0 records
2017-01-18 03:19:02 dirmngr[30882.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 03:19:03 dirmngr[30882.6] DBG: dns:
resolve_dns_name(oteiza.siccegge.de): Success
2017-01-18 03:19:03 dirmngr[30882.6] resolve_dns_addr for 'oteiza.siccegge.de':
'oteiza.siccegge.de' [already known]
2017-01-18 03:19:03 dirmngr[30882.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 03:19:03 dirmngr[30882.6] number of system provided CAs: 142
2017-01-18 03:19:03 dirmngr[30882.6] DBG: http.c:connect_server: trying
name='oteiza.siccegge.de' port=11371
2017-01-18 03:19:05 dirmngr[30882.6] DBG: dns:
resolve_dns_name(oteiza.siccegge.de): Success
2017-01-18 03:19:05 dirmngr[30882.6] can't connect to 'oteiza.siccegge.de':
Permission denied
2017-01-18 03:19:05 dirmngr[30882.6] error connecting to
'http://oteiza.siccegge.de:11371': Permission denied
2017-01-18 03:19:05 dirmngr[30882.6] command 'KS_GET' failed: Permission denied
2017-01-18 03:19:05 dirmngr[30882.6] handler for fd 6 terminated
2017-01-18 03:19:05 dirmngr[30882.6] handler for fd 6 started
2017-01-18 03:19:05 dirmngr[30882.6] connection from process 30921 (1000:1000)
2017-01-18 03:19:05 dirmngr[30882.6] handler for fd 6 terminated

Jan 18 2017, 9:24 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

fwiw, i'm seeing fewer errors with this version than i was before, perhaps
because we're addressing servers via tor by name instead of by IP address, which
means that we're not tickling the IPv6 issue quite as often?

The failure with oteiza.siccegge.de might actually just be the IPv6 issue
itself, since there is no IPv4 address for it. I can actually force the issue
if i just add the following line to the dirmngr.conf generated in my reproducer
script:

    keyserver hkp://oteiza.siccegge.de

but of course it's a faster failure, because there isn't a dozen DNS A->PTR
round-trips.

Can you explain why dirmngr does the DNS roundtrip lookup, mapping from the
pool's A and AAAA addresses back to names? It seems like it'd be a lot simpler
(and faster, and less error-prone) to avoid the PTR lookups if we have the IP
addresses already.

Jan 18 2017, 9:21 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

I note here that the "oteiza.siccegge.de" domain name might be supplied by PTR
records for both its v4 and v6 addresses, and it appears to have a AAAA record,
but it doesn't have any *forward* A record.

I'm baffled by the fact that you're not seeing these errors, and not sure what
to do about it. What version of tor are you running? how is it configured?

i'm running the stock debian tor package, version 0.2.9.8-2.

Jan 18 2017, 9:03 AM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

I've tried with the latest patches and i still see failures :(

gpg: keybox '/home/dkg/tmp/tmp.nchsng7MNY/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 9 11 6 4 10 5 7 8 2* 3 1
S # 1 6 4 sks.spodhuis.org v6=[2a02:898:31:0:48:4558:73:6b73] v4=94.142.242.225
S # 2 6 4 oteiza.siccegge.de v6=[2a01:4a0:59:1000:223:9eff:fe00:100f]
v4=92.43.111.21
S # 3 6 prod00.keyserver.dca.witopia.net v6=[2606:9500:201:1::141]
S # 4 6 4 gpg.NebrWesleyan.edu v6=[2606:1c00:2802::b] v4=192.94.109.73
S # 5 6 4 d hufu.ki.iif.hu v6=[2001:738:0:600:216:3eff:fe02:42]
v4=193.224.163.43 (1s)
S # 6 6 4 gozer.rediris.es v6=[2001:720:418:caf1::8] v4=130.206.1.8
S # 7 4 ip-209-135-211-141.ragingwire.net v4=209.135.211.141
S # 8 4 mud.stack.nl v4=131.155.141.70
S # 9 4 ams.sks.heypete.com v4=51.15.53.138
S # 10 4 host-37-191-238-78.lynet.no v4=37.191.238.78
S # 11 4 cryptonomicon.mit.edu v4=18.9.60.141
OK
2017-01-18 02:56:23 dirmngr[9098] listening on socket
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/S.dirmngr'
2017-01-18 02:56:23 dirmngr[9099.0] permanently loaded certificates: 0
2017-01-18 02:56:23 dirmngr[9099.0] runtime cached certificates: 0
2017-01-18 02:56:23 dirmngr[9099.0] failed to open cache dir file
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/crls.d/DIR.txt': No such file or directory
2017-01-18 02:56:23 dirmngr[9099.0] creating directory
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/crls.d'
2017-01-18 02:56:23 dirmngr[9099.0] new cache dir file
'/home/dkg/tmp/tmp.nchsng7MNY/gpg/crls.d/DIR.txt' created
2017-01-18 02:56:24 dirmngr[9099.6] handler for fd 6 started
2017-01-18 02:56:24 dirmngr[9099.6] connection from process 9096 (1000:1000)
2017-01-18 02:56:24 dirmngr[9099.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 02:56:25 dirmngr[9099.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-18 02:56:25 dirmngr[9099.6] DBG: dns: libdns initialized (tor mode)
2017-01-18 02:56:27 dirmngr[9099.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-18 02:56:28 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:28 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'sks.spodhuis.org'
2017-01-18 02:56:28 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'oteiza.siccegge.de'
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:29 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'prod00.keyserver.dca.witopia.net'
2017-01-18 02:56:29 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:30 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:30 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gpg.NebrWesleyan.edu'
2017-01-18 02:56:30 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:31 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): No name
2017-01-18 02:56:31 dirmngr[9099.6] resolve_dns_addr failed while checking
'hkps.pool.sks-keyservers.net': No name
2017-01-18 02:56:32 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:32 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'hufu.ki.iif.hu'
2017-01-18 02:56:32 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:33 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:33 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gozer.rediris.es'
2017-01-18 02:56:33 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:34 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Connection
closed in DNS
2017-01-18 02:56:34 dirmngr[9099.6] resolve_dns_addr failed while checking
'hkps.pool.sks-keyservers.net': Connection closed in DNS
2017-01-18 02:56:35 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:35 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'ip-209-135-211-141.ragingwire.net'
2017-01-18 02:56:35 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:36 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:36 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'hufu.ki.iif.hu' [already known]
2017-01-18 02:56:36 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:37 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:37 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gpg.NebrWesleyan.edu' [already known]
2017-01-18 02:56:37 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'mud.stack.nl'
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:38 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'gozer.rediris.es' [already known]
2017-01-18 02:56:38 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:39 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:39 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'sks.spodhuis.org' [already known]
2017-01-18 02:56:39 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:40 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:40 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'oteiza.siccegge.de' [already known]
2017-01-18 02:56:40 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'ams.sks.heypete.com'
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:41 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'host-37-191-238-78.lynet.no'
2017-01-18 02:56:41 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:42 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:42 dirmngr[9099.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': 'cryptonomicon.mit.edu'
2017-01-18 02:56:42 dirmngr[9099.6] DBG: dns: resolve_dns_addr(): Success
2017-01-18 02:56:42 dirmngr[9099.6] DBG: http.c:connect_server: trying
name='hufu.ki.iif.hu' port=443
2017-01-18 02:56:45 dirmngr[9099.6] DBG: dns: resolve_dns_name(hufu.ki.iif.hu):
Connection closed in DNS
2017-01-18 02:56:45 dirmngr[9099.6] resolving 'hufu.ki.iif.hu' failed:
Connection closed in DNS
2017-01-18 02:56:45 dirmngr[9099.6] can't connect to 'hufu.ki.iif.hu': host not
found
2017-01-18 02:56:45 dirmngr[9099.6] error connecting to
'https://hufu.ki.iif.hu:443': Unknown host
2017-01-18 02:56:45 dirmngr[9099.6] marking host 'hufu.ki.iif.hu' as dead
2017-01-18 02:56:45 dirmngr[9099.6] DBG: http.c:connect_server: trying
name='oteiza.siccegge.de' port=443
2017-01-18 02:56:46 dirmngr[9099.6] DBG: dns:
resolve_dns_name(oteiza.siccegge.de): Success
2017-01-18 02:56:46 dirmngr[9099.6] can't connect to 'oteiza.siccegge.de':
Permission denied
2017-01-18 02:56:46 dirmngr[9099.6] error connecting to
'https://oteiza.siccegge.de:443': Permission denied
2017-01-18 02:56:46 dirmngr[9099.6] command 'KS_GET' failed: Permission denied
2017-01-18 02:56:46 dirmngr[9099.6] handler for fd 6 terminated
2017-01-18 02:56:46 dirmngr[9099.6] handler for fd 6 started
2017-01-18 02:56:46 dirmngr[9099.6] connection from process 9101 (1000:1000)
2017-01-18 02:56:46 dirmngr[9099.6] handler for fd 6 terminated

Jan 18 2017, 8:58 AM · Debian, Bug Report, gnupg, dirmngr

Jan 12 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

gpg: keybox '/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/pubring.kbx' created
gpg: /home/dkg/tmp/tmp.0Ew9D45cz7/gpg/trustdb.gpg: trustdb created
gpg: key 7638D0442B90D010: public key "Debian Archive Automatic Signing Key
(8/jessie) <ftpmaster@debian.org>" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 15 14 13 12 11 10 19 18* 17 16 9 8 7 6 5 4 3 2 1
S # 1 6 [2a02:898:31:0:48:4558:73:6b73]
S # 2 6 [2a01:4a0:59:1000:223:9eff:fe00:100f]
S # 3 6 [2a00:14b0:4200:3000:27::27]
S # 4 6 [2606:9500:201:1::141]
S # 5 6 [2606:1c00:2802::b]
S # 6 6 [2001:bc8:4700:2300::10:f15]
S # 7 6 [2001:bc8:2515::1]
S # 8 6 [2001:720:418:caf1::8]
S # 9 6 [2001:470:1:116::6]
S # 10 4 216.66.15.2
S # 11 4 212.12.48.27
S # 12 4 209.135.211.141
S # 13 4 192.94.109.73
S # 14 4 163.172.29.20
S # 15 4 130.206.1.8
S # 16 4 94.142.242.225
S # 17 4 92.43.111.21
S # 18 4 51.15.53.138
S # 19 4 37.191.238.78
OK
2017-01-12 11:35:25 dirmngr[833] listening on socket
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/S.dirmngr'
2017-01-12 11:35:25 dirmngr[834.0] permanently loaded certificates: 0
2017-01-12 11:35:25 dirmngr[834.0] runtime cached certificates: 0
2017-01-12 11:35:25 dirmngr[834.0] failed to open cache dir file
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:35:25 dirmngr[834.0] creating directory
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d'
2017-01-12 11:35:25 dirmngr[834.0] new cache dir file
'/home/dkg/tmp/tmp.0Ew9D45cz7/gpg/crls.d/DIR.txt' created
2017-01-12 11:35:26 dirmngr[834.6] handler for fd 6 started
2017-01-12 11:35:26 dirmngr[834.6] connection from process 831 (1000:1000)
2017-01-12 11:35:26 dirmngr[834.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:35:27 dirmngr[834.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-12 11:35:27 dirmngr[834.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:35:28 dirmngr[834.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:9500:201:1::141]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:2515::1]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '216.66.15.2'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '212.12.48.27'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '209.135.211.141'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '192.94.109.73'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '163.172.29.20'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '130.206.1.8'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '94.142.242.225'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '92.43.111.21'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '51.15.53.138'
2017-01-12 11:35:28 dirmngr[834.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '37.191.238.78'
2017-01-12 11:35:28 dirmngr[834.6] DBG: http.c:connect_server: trying
name='51.15.53.138' port=443
2017-01-12 11:35:28 dirmngr[834.6] DBG: dns: resolve_dns_name(51.15.53.138): Success
2017-01-12 11:35:31 dirmngr[834.6] DBG: http.c:1706:socket_new: object
0x00007f57e400a5d0 for fd 8 created
2017-01-12 11:35:34 dirmngr[834.6] DBG: http.c:request:
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> GET
/pks/lookup?op=get&options=mr&search=0x126C0D24BD8A2942CC7DF8AC7638D0442B90D010
HTTP/1.0\r\n
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> Host:
hkps.pool.sks-keyservers.net:443\r\n
2017-01-12 11:35:34 dirmngr[834.6] DBG: http.c:request-header:
2017-01-12 11:35:34 dirmngr[834.6] DBG: >> \r\n
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 terminated
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 started
2017-01-12 11:35:37 dirmngr[834.6] connection from process 841 (1000:1000)
2017-01-12 11:35:37 dirmngr[834.6] handler for fd 6 terminated

Jan 12 2017, 5:39 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

gpg: keybox '/home/dkg/tmp/tmp.swbfPRERsO/gpg/pubring.kbx' created
gpg: keyserver receive failed: Server indicated a failure
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
OK
2017-01-12 11:36:01 dirmngr[851] listening on socket
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/S.dirmngr'
2017-01-12 11:36:01 dirmngr[852.0] permanently loaded certificates: 0
2017-01-12 11:36:01 dirmngr[852.0] runtime cached certificates: 0
2017-01-12 11:36:01 dirmngr[852.0] failed to open cache dir file
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:36:01 dirmngr[852.0] creating directory
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d'
2017-01-12 11:36:01 dirmngr[852.0] new cache dir file
'/home/dkg/tmp/tmp.swbfPRERsO/gpg/crls.d/DIR.txt' created
2017-01-12 11:36:02 dirmngr[852.6] handler for fd 6 started
2017-01-12 11:36:02 dirmngr[852.6] connection from process 849 (1000:1000)
2017-01-12 11:36:02 dirmngr[852.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:12 dirmngr[852.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net): Server indicated a failure
2017-01-12 11:36:12 dirmngr[852.6] command 'KS_GET' failed: Server indicated a
failure <Unspecified source>
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 terminated
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 started
2017-01-12 11:36:12 dirmngr[852.6] connection from process 854 (1000:1000)
2017-01-12 11:36:12 dirmngr[852.6] handler for fd 6 terminated

Jan 12 2017, 5:39 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

gpg: keybox '/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/pubring.kbx' created
gpg: keyserver receive failed: Permission denied
S # hosttable (idx, ipv6, ipv4, dead, name, time):
S # 0 hkps.pool.sks-keyservers.net
S # . hkps.pool.sks-keyservers.net
S # . --> 15 14 13 12 11 10 19 18 17 16 9 8 7 6 5 4 3 2* 1
S # 1 6 [2a02:898:31:0:48:4558:73:6b73]
S # 2 6 [2a01:4a0:59:1000:223:9eff:fe00:100f]
S # 3 6 [2a00:14b0:4200:3000:27::27]
S # 4 6 [2606:9500:201:1::141]
S # 5 6 [2606:1c00:2802::b]
S # 6 6 [2001:bc8:4700:2300::10:f15]
S # 7 6 [2001:bc8:2515::1]
S # 8 6 [2001:720:418:caf1::8]
S # 9 6 [2001:470:1:116::6]
S # 10 4 216.66.15.2
S # 11 4 212.12.48.27
S # 12 4 209.135.211.141
S # 13 4 192.94.109.73
S # 14 4 163.172.29.20
S # 15 4 130.206.1.8
S # 16 4 94.142.242.225
S # 17 4 92.43.111.21
S # 18 4 51.15.53.138
S # 19 4 37.191.238.78
OK
2017-01-12 11:36:23 dirmngr[866] listening on socket
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/S.dirmngr'
2017-01-12 11:36:23 dirmngr[867.0] permanently loaded certificates: 0
2017-01-12 11:36:23 dirmngr[867.0] runtime cached certificates: 0
2017-01-12 11:36:23 dirmngr[867.0] failed to open cache dir file
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d/DIR.txt': No such file or directory
2017-01-12 11:36:23 dirmngr[867.0] creating directory
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d'
2017-01-12 11:36:23 dirmngr[867.0] new cache dir file
'/home/dkg/tmp/tmp.vOaRFt7s4L/gpg/crls.d/DIR.txt' created
2017-01-12 11:36:24 dirmngr[867.6] handler for fd 6 started
2017-01-12 11:36:24 dirmngr[867.6] connection from process 864 (1000:1000)
2017-01-12 11:36:24 dirmngr[867.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:26 dirmngr[867.6] DBG: dns:
getsrv(_pgpkey-https._tcp.hkps.pool.sks-keyservers.net) -> 0 records
2017-01-12 11:36:26 dirmngr[867.6] DBG: dns: libdns initialized (tor mode)
2017-01-12 11:36:27 dirmngr[867.6] DBG: dns:
resolve_dns_name(hkps.pool.sks-keyservers.net): Success
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a02:898:31:0:48:4558:73:6b73]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a01:4a0:59:1000:223:9eff:fe00:100f]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2a00:14b0:4200:3000:27::27]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:9500:201:1::141]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2606:1c00:2802::b]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:4700:2300::10:f15]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:bc8:2515::1]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:720:418:caf1::8]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '[2001:470:1:116::6]'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '216.66.15.2'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '212.12.48.27'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '209.135.211.141'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '192.94.109.73'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '163.172.29.20'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '130.206.1.8'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '94.142.242.225'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '92.43.111.21'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '51.15.53.138'
2017-01-12 11:36:27 dirmngr[867.6] resolve_dns_addr for
'hkps.pool.sks-keyservers.net': '37.191.238.78'
2017-01-12 11:36:27 dirmngr[867.6] DBG: http.c:connect_server: trying
name='2a01:4a0:59:1000:223:9eff:fe00:100f' port=443
2017-01-12 11:36:27 dirmngr[867.6] DBG: dns:
resolve_dns_name(2a01:4a0:59:1000:223:9eff:fe00:100f): Success
2017-01-12 11:36:27 dirmngr[867.6] can't connect to
'2a01:4a0:59:1000:223:9eff:fe00:100f': Permission denied
2017-01-12 11:36:27 dirmngr[867.6] error connecting to
'https://[2a01:4a0:59:1000:223:9eff:fe00:100f]:443': Permission denied
2017-01-12 11:36:27 dirmngr[867.6] command 'KS_GET' failed: Permission denied
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 terminated
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 started
2017-01-12 11:36:27 dirmngr[867.6] connection from process 869 (1000:1000)
2017-01-12 11:36:27 dirmngr[867.6] handler for fd 6 terminated

Jan 12 2017, 5:38 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

Here's the reproducer script i'm using:

--------

#!/bin/bash

WORKDIR=$(mktemp -d)
export GNUPGHOME="$WORKDIR/gpg"
mkdir -p -m 0700 "$GNUPGHOME"
cat > "$GNUPGHOME/dirmngr.conf" <<EOF
debug dns,network
verbose
use-tor
log-file $WORKDIR/dirmngr.log
EOF

gpg --recv 126C0D24BD8A2942CC7DF8AC7638D0442B90D010

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye

cat "$WORKDIR/dirmngr.log"

rm -rf "$WORKDIR"

I just ran it three times in a row, and i got three different results, which
i'll paste as separate messages for easier visibility.

Jan 12 2017, 5:37 PM · Debian, Bug Report, gnupg, dirmngr
dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

They don't solve the bug for me, unfortunately. with those patches applied, i
now get "permission denied" errors:

an 11 15:57:18 alice dirmngr[20203]: DBG: gnutls:L3: ASSERT:
mpi.c[_gnutls_x509_read_uint]:246
Jan 11 15:57:18 alice dirmngr[20203]: DBG: gnutls:L5: REC[0x7f07c0008640]:
Allocating epoch #0
Jan 11 15:57:18 alice dirmngr[20203]: can't connect to
'2a02:898:31:0:48:4558:73:6b73': Permission denied
Jan 11 15:57:18 alice dirmngr[20203]: error connecting to
'https://[2a02:898:31:0:48:4558:73:6b73]:443': Permission denied

which also don't mark the IPv6 address as dead, so they're effectively permanent
until i clear them out.

As a workaround, i've been clearing out all IPv6 addresses with this terrible hack:

0 dkg@alice:~$ cat bin/dirmngr-flush-ipv6
#!/bin/bash

drop all IPv6 keyservers from dirmngr:

gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye |\

awk '/\[.*:.*\]/{ print "keyserver --dead " $5 } ' |\
gpg-connect-agent --dirmngr

0 dkg@alice:~$

Jan 12 2017, 12:37 AM · Debian, Bug Report, gnupg, dirmngr

Jan 5 2017

dkg added a comment to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.

I was wrong about Tor and IPv6 -- Tor has had IPv6 support for years, so
something else is wrong...

Jan 5 2017, 10:52 PM · Debian, Bug Report, gnupg, dirmngr
dkg set External Link to https://bugs.debian.org/849845 on T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.
Jan 5 2017, 10:47 PM · Debian, Bug Report, gnupg, dirmngr
dkg added projects to T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set: dirmngr, gnupg, Bug Report, Debian.
Jan 5 2017, 10:02 PM · Debian, Bug Report, gnupg, dirmngr
dkg set Version to 2.1.17 on T2902: dimrngr over tor fails obscurely on IPv6 records when NoIPv6Traffic flag is set.
Jan 5 2017, 10:02 PM · Debian, Bug Report, gnupg, dirmngr

Dec 9 2016

dkg added a comment to T2862: support session key extraction and overriding for gpgsm.

This would emit the "content-encryption key", as specified in
https://tools.ietf.org/html/rfc5652#section-6.3

Dec 9 2016, 5:18 AM · gnupg24, Feature Request, gnupg (gpg23)

Dec 6 2016

dkg added a comment to T2857: gpg-agent crashes regularly, out of core in secure memory allocations.

ah right, "ulimit -l" says 64 (kbytes) on my Linux system as well. According to
mlock(2) that's since kernel 2.6.9.

So i think it's worth adopting the supplied patch as a workaround at least (i
can confirm that it resolves the specific use case described in T2857 (dkg on Dec 05 2016, 05:47 PM / Roundup)), and i
agree with you that we should extend libgcrypt to extend secure memory allocation.

it's not clear to me that swap is outside the trust boundary anyway these days,
and modern systems should prefer encrypted swap where possible.

Dec 6 2016, 5:49 PM · gnupg (gpg22), Bug Report, gnupg, gpgagent
dkg added a comment to T2857: gpg-agent crashes regularly, out of core in secure memory allocations.

is the only goal of the secure memory to keep the RAM from being written to
swap, or are there other goals of secure memory? why is it unlikely that a new
block of memory can be mlock'd? what are the consequences of the new block not
being mlock'd? will it still be treated as secure memory?

crashing in the event that we run out of secure memory is simply not acceptable
these days, especially in a model where we have persistent long-term daemons
that people expect to remain running.

Dec 6 2016, 5:18 PM · gnupg (gpg22), Bug Report, gnupg, gpgagent
dkg added a comment to T2857: gpg-agent crashes regularly, out of core in secure memory allocations.

I just posted 0001-agent-Respect-enable-large-secmem.patch to gnupg-devel:

https://lists.gnupg.org/pipermail/gnupg-devel/2016-December/032285.html

Dec 6 2016, 5:12 PM · gnupg (gpg22), Bug Report, gnupg, gpgagent
dkg added a comment to T2857: gpg-agent crashes regularly, out of core in secure memory allocations.

D400: 927_0001-agent-Respect-enable-large-secmem.patch

Dec 6 2016, 5:12 PM · gnupg (gpg22), Bug Report, gnupg, gpgagent

Dec 5 2016

dkg added a comment to T2863: gpg --export-ssh-key dies with "ohhhh jeeee".

This is a duplicate of bug 2848

Dec 5 2016, 9:28 PM · Bug Report, gnupg