Please use the systemd unit files as shipped upstream. This allows the agent to be launched automatically whenever someone tries to use one of its sockets, but doesn't pre-emptively launch the agent until needed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 14 2017
Aug 11 2017
I'm not sure i understand why i'm "chasing a ghost" -- i'm reporting the experience of a developer (me!) who tried to use gpgme, read all the docs, and was still surprised and dismayed by the metadata leakage.
Thanks for the improvements, Marcus!
Aug 8 2017
Can you describe the problems it would cause for gpgme? gpgme already currently expects that gpgv will return a failure for signatures made before the validity window of the key. so gpgme won't break just because gpgv is capable of returning a non-zero response.
Aug 7 2017
Aug 5 2017
ah, great! sorry i got confused :)
Aug 4 2017
fwiw, faked-system-time is used in several non-gnupg packages in debian already.
fwiw, faked-system-time is used in several non-gnupg packages in debian already.
Aug 2 2017
Aug 1 2017
Jul 28 2017
why should it wait for the timeout in the pselect call? shouldn't it be able to respond immediately to the final connection closing?
Yes, that commit was in 2010, but it was on the 2.1 branch, which never saw wide distribution until this year, which means that there are test suites (like the one mentioned in request-tracker) which simply fail hard when used against gpg 2.1. Is there explicit guidance that the GnuPG project wants to give to downstreams like request-tracker?
Jul 24 2017
Jul 20 2017
I'd like to hear a little more about the use cases we imagine for Anonymous OpenPGP certificates.
Jul 14 2017
I'm re-opening this ticket because i think Valodim has clarified what he meant, which is different than what werner closed the ticket for.
Users expect to be able to make signatures (or to fail to make signatures) reliably and understandably. the fact that some pinentries fail in some obscure combinations of circumstances makes the process of making signatures unreliable and incomprehensible.
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.
Thinking about it more broadly, i think that gpgv (and gpg, when used in signature verification mode) should have a return code that is as close to the true/false underlying semantics that users will want, rather than relying on status messages to distinguish between these cases.
for expiration (or for revocations flagged "key was superseded" instead of "compromised"), you can have a signature made *before* the key's expiration/revocation, but you might be verifying it *after* the key was revoked/expired.
including these tests (or something similar) in the gpg test suite would be a good way to avoid future regressions.
Note that T2923 includes a patch that might help.
My point is that without clear documentation of what is expected, it's pretty hard to tell whether the code is even working or not. Sounds like it isn't :(
I don't think this issue is actually resolved. there's a feature here (i think) but it's not documented to the point where anyone can figure out how to use it. If there's no way to use it, the feature should be removed (or at least deprecated).
Jul 12 2017
I don't see how this duplicates T3074. If the web form is going to encourage people to ask for the team's encryption keys, it should just provide the encryption keys directly.
Agreed, i think the OP is asking for X when he wants Y, so that makes this request a little bit strange.
I don't think that's what we want. An OpenPGP certificate has a claimed temporal validity window: from the creation date of the certificate to its expiration or revocation date.
Jul 6 2017
Jul 5 2017
Jun 26 2017
fwiw, i've also opened a bug for sbuild asking it to not force the locale into non-UTF-8: https://bugs.debian.org/866023
fwiw, i also find this password quality indicator rather dubious.
T2103 is the right place to discuss the password quality algorithm, not here.
Jun 21 2017
In many cases, it's possible to make two connections (e.g. via ssh) to such a server, and in one of those connections explicitly do:
aiui, the point here is to have the user "service" get triggered somehow (through pam's pam_systemd.so's session module?) before ssh goes ahead and forms the socket. is that right? If the pre-launch mechanism is pam, is there a reason to do it as a systemd user service? That won't work for systems that have pam but don't have systemd, whereas a pam module that creates these will work.
Jun 20 2017
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.
May 23 2017
If you're putting a note at the top of ChangeLog-2011, it should probably mention where the *other* changelogs are, not just an explanation of what this file is doing here. And while this does explain to a user who has bothered to read it what's going on, it's still not particularly friendly.
May 22 2017
thanks for considering this for > 2.2.
I'm not sure i understand. Current changelogs don't go into the source tree, and yet that's not a violation of the GPL, so clearly keeping changelogs in the source tree isn't a requirement in general.
May 19 2017
I'm using 2.1.21-2 from the debian experimental build, and i'm not seeing this misbehavior.
I've pushed rGdee244b48060 in the branch T3172 as a proposed fix for this.
May 18 2017
May 9 2017
I didn't mean to remove the capability of having a restricted "extra-socket". I meant that we could remove (or deprecate) the capability of placing the restricted "extra-socket" at an arbitrary location. I agree with you that having the restricted "extra-socket" is an important capability that gpg shouldn't remove.
Those scripts are likely already broken if their input happens to be different than what they expect, so i don't much care about "breaking" them. That said, it sounds like you're suggesting that the default mode will just be "--decrypt" and we'll let people continue using it that way.
May 5 2017
Apr 26 2017
Can we activate this for --import and --recv-key as guilhem requested?
I've raised the priority here because this bug gets reported regularly and it seems a shame that we haven't fixed it yet, despite having a patch available for quite some time.
The branch dkg/T1967 contains a fix for this. Please review!
I've just pushed rGde441cb9cc87, taken from the gnupg-devel mailing list, message-id: 20160414161817.GA9527@gnu.org
Apr 25 2017
I think it only lists the wrong "extra socket path" when one is specified in gpg-agent.conf, right?
Apr 19 2017
Apr 17 2017
I've just pushed a branch dkg/no-skel-files which implements this change.
Can you try with --standard-resolver ?
Apr 6 2017
I just merged the current git head over on zelenka, which includes b83903f59ec5d49ac579f263da70ebc8dc3645b5, and managed to still get the same segfaults.
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 4 2017
I don't have one of these systems handy to test with, but if the fix in dee026d7 does what it says it does, this sounds like it's probably OK to close in my book. if there are more problems, i'm sure we can re-open it.
Apr 3 2017
Sure:
Mar 28 2017
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 22 2017
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 14 2017
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 1 2017
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?
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:~$
Feb 22 2017
Feb 21 2017
Are you using tor? if so, is your tor daemon up and running, and actively
connecting to the outside world?