Weel, required if you cange an .y file.

Bison is required.
I pushed a change which prints a note if yacc is not Bison.

I was unaware that the released version does not require it.

In that case it's no bug imo. because otherwise we would also need to work with
older autotools versions etc.

Bison is a maintainer tool and regualr builds do not require it.
I am also surprised that you can build it with a regular(?) yacc.

This is fixed in 3703a4723899d7563937b4b99f5bbe4dd8d3dfed. We will release a
minor update really soon now.

I'm attaching the lsof and strace transcript in text form so it can be read
without linebreaks

btw. reason for this report is a setup of WKS where you require most recent
modern gnupg on long time distro running servers.

John is using 2.1.14, but this bug was fixed in 2.1.15.

This is apparently just re-reported on gnupg-users:

https://lists.gnupg.org/pipermail/gnupg-users/2016-October/056892.html

So i don't think it's fixed.

And fwiw, it seems like a clear bug to me if i use "ssh-add" and then it is not
added to the agent.

From the ssh-add's client's perspective, some keys are magically never added,
but others are. This kind of mystery behavior is confusing and frustrating. If
gpg-agent is going to handle the ssh-agent protocol, it should aim toward behave
as the user of the ssh-agent protocol expects, regardless of whether the user
knows that they're using gpg-agent or some other implementation.

thank you for taking time to formulate this correctly, dkg. :)

regarding symlinks, i got the idea from reading the caff source code. after a
quick chat with the caff author, i was pointed towards that discussion:

https://lists.gnupg.org/pipermail/gnupg-devel/2015-January/029301.html

... where Werner Koch suggests symlinks as a solution.

in my opinion, the solution is sub-optimal: symlinks increases the attack
surface and adds un-necessary overhead. i would prefer an a commandline flag
(e.g. --agent-socket) or environment variable to be able to select relevant
agents...

the same applies to dirmngr, apparently - caff creates symlinks for both the
agent and dirmngr. i am not sure why, but i suspect I may have to do the same,
since I have seen stray dirmngr processes lying around in my session. a
different issue, maybe, but related, implementation-wise.

Hello,

I'm using RedHat Linux which already had a version of GnuPG installed. (2.0.14)
I'm not sure what process was used to install it. I downloaded the latest
tar-ball of GnuPG Stable 2.0.30 and installed it as per the process described in
the "HOW-TO". But when I check for the version using gpg --version, it gives me
the older version 2.0.14 instead of 2.0.30. Also , there were no errors while I
installed 2.0.30 either in compilation or installation. I'm not sure why the
--version command is still displaying the old version then.

So, regarding Qt, the issue has been acknowledged
(https://bugreports.qt.io/browse/QTBUG-56452). Using IBus as suggested in
https://bugreports.qt.io/browse/QTBUG-49438, I know have dead keys working
properly in most apps. But…

Previously, the situation was as following:

— pinentry-qt4 was working everywhere.
– pinentry-qt was not working properly for me because I wasn’t able to input
some characters.
– pinentry-gnome3 wasn’t showing up in Thunderbird/Enigmail, but worked OK in a
terminal (GETPIN).
– pinentry-gtk-2 was working properly in a terminal (GETPIN), but not in
Thunderbird/Enigmail (deciphering failed, with the right passphrase obviously).

And now:

– pinentry-qt4 doesn’t exist anymore.
– pinentry-qt is as pinentry-gtk-2 was before: works OK in a terminal (GETPIN),
but not in Thunderbird (fails to decipher). Sighs…
– pinentry-gnome3 does show up in Thunderbird/Enigmail, and works correctly. I’m
currently using this one, even if that’s not totally satisfying.
– pinentry-gtk-2 doesn’t take my dead keys into account anymore.

For the last one, honestly I don’t care, gtk2 is being phased out, and it’s
probably not an issue on pinentry side.

However, the fact pinentry-qt doesn’t work correctly in Thunderbird/Enigmail is
strange. Do you think this is an issue with pinentry-qt or these programs?

We now have a macOS box, and are building our software on it using Jenkins.

On that box, I also see the gpgtar test failing in about 14% of all runs. There
is something to be learned here.

To investigate, we need more information. What OS are you using, how did you
install 2.0.14, how did you install 2.0.30, and what exactly do you mean by
"reflecting the older version"?

Fixed in 683620c4.

from a question on the ML

gpg-connect-agent --dirmngr

GETINFO dnsinfo

OK - ADNS w/o Tor support

GETINFO tor

ERR 167772416 False <Dirmngr> - Tor mode is NOT enabled

I'm going to close this due to inactivity. Feel free to reopen this with more
information.

I'm going to close this due to inactivity. Feel free to reopen it with more
information.

Agreed, but i ran into this while looking at python-gnupg, which is now failing
when using GnuPG 2.1. so they're facing breakage either way. It would be
better to have all current releases doing the expected behavior than to imagine
that we can bump this variance in behavior along indefinitely.

I hesitate to fix this for 1.4 - if people are using this they are probably
working around it and a fix would break that.

There is a plethoria of reasons why a user ID is not valid. The most
common one has been a mssing self-signature, thus this note. Newer
releases of older branches actually know about new algorithms and may
print some info about this; but they are not able to handle them.

Here is what the current 1.4 prints for an ed25519/cv25519 key:

$ gpg1 --no-options -v --import <ed25519-cv25519-sample-1.asc
gpg: armor header: Version: GnuPG v2
gpg: can't handle public key algorithm 22
gpg: can't handle public key algorithm 18
gpg: pub 0?/2A020D0A 2016-06-22 patrice.lumumba@example.net
gpg: key 2A020D0A: unsupported public key algorithm on user ID
"patrice.lumumba@example.net"
gpg: key 2A020D0A: unsupported public key algorithm
gpg: key 2A020D0A: skipped user ID "patrice.lumumba@example.net"
gpg: key 2A020D0A: skipped subkey
gpg: key 2A020D0A: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg: w/o user IDs: 1

The problem is pretty obvious. You need to use -v (--verbose) to see
all these messages.

If a apply that fix to an unmodified 2.1.15, my problem is solved:
My test case (importing a PKCS#12 file with pinentry-mode=loopback if the agent
has not been started before) now works. Thank you!

If a apply that fix to an unmodified 2.1.15, my problem is solved. Thank you!

ping

lechten: I agree with justus' evaluation. Further we can't change the sematics
of --default-cert-expire in the way you want that; it would not be compatible.

Fixed with 2.1.14.

Look at what the man page says on how to specify a user id:

• By exact match on an email address. This is indicated by enclosing the email address in the usual way with left and right angles. <heinrichh@uni-duesseldorf.de>

The default however is a substring match on the entire user id. Note that
issue2359 is also about this and it may introduce a slighlty modified way on how
a key is specified by a mail address.

Should only be chnaged for master, though.

Duplicate of T2359

We track this now under T2359