Werner: I think the source tarball you distribute should be changed not to
include the .moc files as they depend on the qt version used when you generate
the tarballs.

MOC should be detected during configure (and otherwise pinentry-qt should be
disabled) and MOC should be used to generate the moc files. If this does not
work as expected this might have been caused by my limited Make and autotools
skills ;-)

Yes, it is part of the gpg4win, it is the latest version. 2.2.3 but the last
versions also have the same problem.

Understood - would you like me to fix with automake 1.10, or park this
for a merge post-Jessie ?

The GIT version has the change to redirect sockets so to make it wok on shared
and NFS mounted home directories.

You need to prepare a file with this content:

%Assuan%
socket=/what/ever/is/the/real/socket

Exactly two lines, no extra white space. Store this as ~/.gnupg/S.gpg-agent

One is an enum, the other an int - not a problem according to the C specs.

From where did you get the gpa.exe - was it part of gpg4win; if so which version?

D273: 534_fix_return_type__gcry_vcontrol.patch

I'll add the logs to the "issue" asap.

p.s. Not sure of effect of creating the file named socket in the current path -
as it is an NFS-v3 mounted filesystem. If you give a change (to test) that opens
the socket in e.g., /tmp, I can add that and test.

Looking at the log files - seems basic error is because there is "No secret key".

Should I have done something before running "make check"?

Some examples:
Test: armencrypt.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: two@example.com: skipped: No public key
gpg: plain-1: encryption failed: No public key

Test: armor.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
armor.test: checking: armored_key_8192
gpg: /data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp/trustdb.gpg: trustdb
created
gpg: key DE415B0E: public key "Susumu OSAWA <susumu-o@goforward.org>" imported
gpg: can't connect to the agent: IPC connect call failed
gpg: Total number processed: 1
gpg: imported: 1
armor.test: the armored_key_8192 bug is back in town

Test: clearsig.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: no default secret key: No secret key
gpg: plain-1: clearsign failed: No secret key
...skipping...

Test: conventional-mdc.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: IDEA encrypted data
gpg: encrypted with 1 passphrase
...skipping...

Test: conventional.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: can't open 'plain-2': No such file or directory
gpg: symmetric encryption of 'plain-2' failed: No such file or directory
...skipping...

Test: decrypt-dsa.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: encrypted with ELG key, ID CB879DE9
gpg: decryption failed: No secret key
...skipping...

Test: decrypt.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: encrypted with ELG key, ID 47BE2775
gpg: decryption failed: No secret key

Test: decrypt.test
GNUPGHOME=/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0/tests/openpgp
gpg: encrypted with ELG key, ID 47BE2775
gpg: decryption failed: No secret key

michael@x054:[/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0]ln -s tests AIX-tests
michael@x054:[/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0]tar cf -
./AIX-tests/openpgp | bzip2 >AIX-tests_openpgp.tar.bz2
tar: ./AIX-tests/openpgp/S.gpg-agent: socket ignored
michael@x054:[/data/prj/gnu/gcrypt/gnupg/gnupg-2.1.0]ls -li
./AIX-tests/openpgp/S.gpg-agent
182715173 srwxrwxrwx 1 root system 0 Dec 03 14:29
./AIX-tests/openpgp/S.gpg-agent

i.e., Sending the whole directory...

re: GCC and bug - as I replied per email. No idea.

automake 1.14 is not yet supported becuase it defaults to the new parallel tests
and automake 1.11 has no way to disable this tests (serial-tests option in 1.14).

After the release of Debian Jessie I plan to migrate to 1.14 and drop support
form earlier automakes.

What is the dscription of errno=141 ?

The test write log files for each test. Can you please send or upload
tests/openpgp/version.test.log - that should give a hint what is going
wrong.

I also wonder about some of the diagnostics:

  t-stringhelp.c: In function 'test_strconcat':
  t-stringhelp.c:201:20: warning: missing sentinel in function call  [-Wformat]

If you look at the code

  out = strconcat ("1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                   "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                   "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                   "1", "2", "3", "4", "5", "6", "7", "8", "9", "10",
                   "1", "2", "3", "4", "5", "6", "7", NULL);

you see that a sentinel (NULL) is there. From the header files:

  #if __GNUC__ >= 4
  # define GNUPG_GCC_A_SENTINEL(a) __attribute__ ((sentinel(a)))
  #else
  # define GNUPG_GCC_A_SENTINEL(a)
  #endif

  [..]
  /* Concatenate the string S1 with all the following strings up to a
     NULL.  Returns a malloced buffer with the new string or NULL on a
     malloc error or if too many arguments are given.  */
  char *strconcat (const char *s1, ...) GNUPG_GCC_A_SENTINEL(0);

is gcc 4.7.4 known for having such a bug?

oh, and this appears to be the case for 1.4.x, 2.0.x, and 2.1.x

That link to the debian bts is a little wacky, somehow roundup is attaching the
comma to the end of it. it should be: https://bugs.debian.org/771976

Adding make and make check as I see it on screen.

D272: 530_exechelp-posix.c.patch

On 12/02/2014 10:14 PM, Daniel Kahn Gillmor via BTS wrote:

Daniel Kahn Gillmor <dkg@fifthhorseman.net> added the comment:

Any word on this? It would be nice to see something like this merged.

Probably due to T1774 which has beend fixed.

Any word on this? It would be nice to see something like this merged.

kmail2 4.14.3 fails to terminate gpg 2.1.0 instances on failed attempt to
attach public keys: https://bugs.kde.org/show_bug.cgi?id=341501

KMail2 4.14.3 cannot attach public keys when using GnuPG 2.1.0:
https://bugs.kde.org/show_bug.cgi?id=341490

That is... just far too obvious for words. *facepalm*

Okay, this works nicely for my needs. Wrapper scripts can turn it into a
site-wide policy.

I can confirm it too. Thank you for this fix.

confirmed

You need to create a redirection file for ssh too:

Set contents of ~/.gnupg/S.gpg-agent.ssh to:
%Assuan%
socket=${HOME}/.gnupg/S.gpg-agent.ssh-${HOSTNAME}

BTW, I just commtied the missing chnages to dirmngr and scdaemon.

For easier debugging you set a log file for gpg-agent or even better set that
log file to a socket in gpg-agent.conf
log-file socket:////home/foo/.gnupg/S.log
and the run
watchgnupg --time-only --force /home/foo/.gnupg/S.log
in another xterm.

Commit f1c3eb4 fixes this.

Hi again -

Exporting HOSTNAME worked, thanks.

I'm still not seeing a per-host ssh agent socket, though. Maybe i'm missing
something, but here's exactly what i'm doing:

Set contents of ~/.gnupg/S.gpg-agent to:
%Assuan%
socket=${HOME}/.gnupg/S.gpg-agent-${HOSTNAME}

(newlines after each of the two lines)

~/.gnupg/gpg-agent.conf contents:
enable-ssh-support
default-cache-ttl 7200
max-cache-ttl 14400
default-cache-ttl-ssh 7200
max-cache-ttl-ssh 14400
no-grab

gpg-connect-agent --verbose /bye

gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
gpg-connect-agent: closing connection to agent

Now i have gpg-agent running, and gpg works as expected.

In ~/.gnupg i see the following sockets:
S.gpg-agent-mymble
S.gpg-agent.ssh

Is the ssh agent socket supposed to be the same filename with .ssh appended, or
is there another line i should be adding to the S.gpg-agent redirect file?

Thanks!

On my system HOSTNAME is not an exported envvar. Thus

export HOSTNAME

should do what you want. ssh support and the new --extra-socket all use the
same code for creating the socket, thus this hould work. I have not tested it
but I am pretty sure. A problem might be that the printed SSH_AUTH_SOCK is not
set to the real socket name - I have not checked this.

D270: 529_patch.diff

I confirm what said by aheinecke. The bug is still there with 2.1.1-beta45 on my
system too.

Looks like a good solution. I got the git versions compiled and gave it
a whirl. I noticed a couple of things:

Looks like a good solution. I got the git versions compiled and gave it
a whirl. I noticed a couple of things:

I tried the exact contents of S.gpg-agent you gave below, but libassuan
is creating the file as $HOME/.gnupg/S.gpg-agent-

In other words the ${HOSTNAME} is blank, which obviously won't work out
very well. :) Presumably a bug. I checked my setup:

echo $HOSTNAME

mymble

hostname

mymble

So the hostname does appear to be set correctly. I'm not quite sure how
i can start it with --verbose to see if it helps show what's happening;
if i try that, with or without a server running it just gives me the
server status.

Second, with --enable-ssh-agent, i noticed that the ssh-agent socket is
still created as ~/.gnupg/S.gpg-agent.ssh. Will this same method be
able to specify a per-host ssh-agent?

In general, though, this looks like it's on the right track! Let me
know if i can do any more testing to help.

If you use the latest Libassuan and GnuPG from GIT you should get what you want.
For example:

rm ~/.gnupg/S.gpg-agent || true
printf '%%Assuan%%\nsocket=${HOME}/.gnupg/S.gpg-agent-${HOSTNAME}\n' \

      > ~/.gnupg/S.gpg-agent

Creates a redirection file which uses HOME and the HOSTNAME. If you start
gpg-agent with --verbose you get a noticed about what has been redirected.

Needs to be implemented for scdaemon and dirmngr as well - but that needs to
wait until Monday.

Thanks werner -- I've filed an upstream issue to bring awareness of the change
to the software I use that was affected (duply/duplicity), I'm sure this is
going to pop up for others as 2.1 becomes more widely adopted. Maybe add
something to the release notes or docs for '--passphrase-fd 0' so folks know a
config change is needed in their apps and gpg-agent? Regardless, I appreciate
your help.

(marking as resolved)

I've changed the category to gpa, adjusted the topic and version to 2.2.3
As you've already described the problem together with GPA here I think this is
better then opening a new bug.

I'll also no longer call this critical as the original data loss problem
(Encrypting files where one has an umlaut -> kleo thinks its a success and
deletes the original) Should be resolved.

The fix in GPA should be fairly easy. Some conversion from native to utf-8 on
input and utf-8 to native on output. So I'm taking this issue.

Werner: Could you please take a look at the patch for gpgtar. I will probably
propose something quite similar for GPA. Not real unicode support but at least
for 8 bit filenames.

I did install gpg4win 2.2.3 which does include the fix for Umlaut. I prefer to
use GPA as frontend for encryption and decryption. For decryption, I did link
.gpg to be always opened with GPA. Unfortunatly if the File or Path to the .gpg
has an Umlaut included the GPA GUI crashes. Only if I use the open button from
GPA the file can be added to the GPA frontend and decrypted. For non-umlaut
files the link to open .gpg works fine. Do you also work on GPA bugs or do I
have to report this under the GPA category?
Thank you & regards,

If you add it to gpg.conf the Pinentry won't be used and there are fir sure
cases where things won't work. In an unattended use I can't see a problem right
now.

We can't change the behaviour of --passpharse-fd; it is widely used and:

  if ( !opt.batch && opt.pinentry_mode != PINENTRY_MODE_LOOPBACK)
    { /* Not used but we have to do a dummy read, so that it won't end
         up at the begin of the message if the quite usual trick to
         prepend the passphtrase to the message is used. */

think would break or - worse - may insert the passphrase into the message.

The passphrase is still used for symmetric only encryption in batch mode.

As I wrote in T1774 (aheinecke on Nov 27 2014, 05:42 PM / Roundup)
I reproduced this Bug with 2.1.1-beta45

Can you test it with the latest git version or the beta at
ftp://ftp.gnupg.org/people/werner/scratch/gnupg-2.1.1-beta35.tar.bz2
?

Roger that, thanks - I've tested it on a VM with my keys and things seem "like
they used to be" for scripting an automated passphrase entry. I specified them
in my ~/.gnupg/pgp.conf and ~/.gnupg/gpg-agent.conf since editing many
individual softwares is not possible at this time, it needs to be backwards
compatible.

What side affects (breaking things?) does having these options permanently
enabled in configs are there? Having the allow in gpg-agent.conf is harmless,
but what about the client side gpg.conf?

If client gpg '--passphrase-fd 0' is useless without '--pinentry-mode loopback',
why not make this an automatic added option (internally) if '--passphrase-fd 0'
is specified? Of what use with gnupg-2.1.x is '--passphrase-fd 0' without
'--pinentry-mode loopback'?

I double-checked the official docs, there's no mention of needing these new
loopback settings in the section for --passphrase-fd 0:

https://www.gnupg.org/documentation/manuals/gnupg/GPG-Esoteric-Options.html#GPG-Esoteric-Options

"If you use 0 for n, the passphrase will be read from STDIN." (but as we know
here, it's not unless the new loopback options are added)

I've opened T1775 and only afterwards noticed that this issue did aleardy
exist ;-)

So here is my mesage from T1775 which further qualifies this issue:

This bug was reported by fersingb on IRC, I could reproduce it.

If you have a public keyring in the .kbx format exporting a key with the full
keyid produces an endless output stream.

To reproduce it I can import any key into a newly created gnupg homedir.
When exporting this again using the fingerprint as identifier the bug is triggered.

My usual gnupghome was automatically migrated still has a pubring.gpg and works.

Setup:
FAKEHOME=$(mktemp -d)
gpg2 --armor --export CA308D95A6332F7056B4DFD194F78CF1265059CD | gpg2 --homedir
$FAKEHOME --import

Triggering the bug:

gpg2 --homedir $FAKEHOME --armor --export CA308D95A6332F7056B4DFD194F78CF1265059CD

The short fingerprint works:

gpg2 --homedir $FAKEHOME --armor --export 265059CD

My current version is yesterdays master (2.1.1-beta45) but the original reporter
used gnupg-2.1.0.

Ah damn,..
Duplicate of
T1774

sorry.

Duplicate of T1774

Like gpgsm has done from its very beginnong, gpg now also does not pknow
anything about the secret keys. This is all delagted to gpg-agent. This means
that telling gpg a passphrase is useless.

But wait. There is a workaround: gpg has the new option

   --pinentry-mode mode
          Set the pinentry mode to mode.  Allowed values for mode are:

          default
                 Use the default of the agent, which is ask.

          ask    Force the use of the Pinentry.

          cancel Emulate use of Pinentry's cancel button.

          error  Return a Pinentry error (``No Pinentry'').

          loopback

                 Redirect Pinentry queries to the caller.  Note that
                 in contrast to Pinentry the user is not prompted
                 again if he enters a bad pass- word.

Thus by using

  gpg --pinentry-mode=loopback

you can do basically the same as with 1.4. It is well tested and
slighly different than in 1.4. Uou also need to configure gpg-agent
with

  --allow-loopback-pinentry

       Allow clients to use the loopback pinentry features; see the
       option pinentry-mode for details.

The problem was with that specific keyserver. If I use another keyserver it
works. The keyserver was the first one returned to me by using the
keys.gnupg.net pool and as gpg 1 works with it.

I've debugged the issue.

The test case is now reduced to:
gpg2 --keyserver hkp://127.0.0.1 --search foobar

Dirmngr logs:

2014-11-26 20:35:55 dirmngr[5892.1] getnameinfo returned for '127.0.0.1':
'localhost'
2014-11-26 20:35:55 dirmngr[5892.1] can't connect to '127.0.0.1': Success
2014-11-26 20:35:55 dirmngr[5892.1] error connecting to
'http://127.0.0.1:11371': System error w/o errno
2014-11-26 20:35:55 dirmngr[5892.1] command 'KS_SEARCH' failed: System error w/o
errno

In my case this is because common/http.c (connect_server) ~ line 2200

  ai->ai_family == AF_INET && (flags & HTTP_FLAG_IGNORE_IPv4)

Returns true for 127.0.0.1 (same for 75.75.183.132 which also explains why it
works with gnupg) the address is skipped but it is the only one -> loop finishes
with no errno set.

It is set in dirmngr/ks-engine-hkp.c which looks to me like: "If it is not
indicated that a host either uses IPv4 nor IPv6 ignore it." Which i find kind of
harsh. At least a debug output like:

      if (!hi->v4 && !hi->v6)
        log_debug("Ignoring host\n");

Should be added there and of course connect_server should return an appropiate
error in case it never actually tried to connect to a server.

While debugging this I think I found another issue. You are using errno after
my_connect calls. If this expands to npth_connect the actual calls are

enter_npth()
sem_post() modifies errno
connect() modifies errno
leave_npth()
sem_wait() //modifies errno

Afaik enter / leave in npth should save errno. I could not confirm that this is
really an issue with a test but I think it is.