If you can't do that we can't help you here. You should contact a commercial
supporter (cf. https://gnupg.org/service.html).

Please note that 1.4.12 has security problems and should be updated anyway.

I changed the category to gnupg because of version 1.4.19 which is the latest
GnuPG-1 release.

Which version of GPGME are you using? Is a GnuPG-2 version also installed (run
"gpg2 --version")?

Duplicate of T2042

Thsi is probably the same as T2042

I have no idea myself. We do not use libdispacth direclty but it may be used
indirectkly be socket or threads code. Thus I would start to look at libnpth -
but it won't be easy to find such a problem.

What about adding an option to not embed the filename even if a file name was
given? It can be hard to convince other tools (e.g. enigmail) to use pipes for
just some of the operations ("cat %f | gnupg" for encryption, but not for
decryption). My workaround with --set-filename "" did not lead to problems yet,
so maybe this is good enough, from a usability point of view. Also, I just had a
look into RFC4880, and it seems that zero-length filenames are perfectly OK:
"This may be a zero-length string."

Thanks for the advice! I totally cargo-culted those flags from some tutorial on the
Internet, so I'm not surprised they're out of whack.

I can hook up a debugger and investigate myself if you give me some idea of where to
look and what to look for.

Simpler: The code does only handle one usage flag and ignores combinations.

The reason for this bug is probably that CAs ignore that anway and it is also
possible that we encountered CAs which bail out if provided with these attributes.

I see what I can do.

1.4 won't handle such a redirection because it does not use libassuan.

2.0 should follow such a redirection but the 2.0 agent is not able to setup a
socket in this way. If there is a real need it can be backported.

Sorry, gpg can't fix bugs in other programs. Having the filename in the cipher
text can be an important information and thus we won't change this. If you do
not want to have a filename embedded, simply do not use a file but pipe the data
to gpg (i.e. read from stdin or another file descriptor).

I can't do it on production environment.
Have to fix it like it is, but still don't know where is an issue.

Thanks for the report. However I am not rigged to replicate this thus we need
to wait for someone elese to look at this.

BTW, you should not use --write-env-file and --use-standard-socket because they
are the defaults in 2.1. --scdaemon-program is only a debug option. GnuPG
knows the full names of all its modules.

That is not a bug. gpg keeps keeps files open and only closes them as needed.
For example before renaming a file under Windows. This is actually the same
uner Windows and Unix but under Unix we have the inode concept and thus we can
rename open files.

1.4.12 is pretty old. Please try 1.4.19 and report whether this problems persists.

iirc, we have another bug report related to this. Right now I am looking into
AIX problems.

I don't know what you mean by "documented the issue". The best thing to do is
to report the bug in the KGpg or Fedora bug tracker.

As this did not happen with 2.0.27 against 1.6.3 (which was part of gpg4win
2.2.4) I ran a git bisect on gnupg:

bdf439035d123e4751e133ad42982673b0c86b75 is the first bad commit
commit bdf439035d123e4751e133ad42982673b0c86b75
Author: Werner Koch <wk@gnupg.org>
Date: Wed Mar 25 10:12:11 2015 +0100

sm: Change default algos to SHA256 (CSR) and AES128 (bulk encryption).

* sm/certreqgen.c (create_request): Change default hash algo.
* sm/gpgsm.c (main): Change default bulk cipher algo.
--

Signed-off-by: Werner Koch <wk@gnupg.org>

I can reproduce the Problem with gpg4win 2.2.5 and under GNU/Linux running
libgcrypt master and gnupg stable branch.

Does not happen with GnuPG master (2.1)

Hi Neal,

I understand your position on this issue.

As an interim heads up, I have documented this issue in the Fedora Forum. As my
post is only a few hours old, I'll keep an eye on it, and will be sure to let
you know if anything interesting shakes out.

Changing PCSC_SHARE_EXCLUSIVE to PCSC_SHARE_SHARED in scd/apdu.c:1560 fixes my
problem *and* has no ill effects on Yubikey operation: gnupg --card-status
interleaved with my application running in a loop at the same time work just
fine, both applications get their proper responses from the card.

This may or may not work with OpenPGP cards other than Yubikey, I have no way to
check...

if (do_compress && cfx.dek->use_mdc && is_file_compressed(filename, &rc2))

  {
    if (opt.verbose)
      log_info(_("'%s' already compressed\n"), filename);
    do_compress = 0;
  }
if (rc2)
  {
    rc = rc2;
    goto leave;
  }

Thanks for doing this. Unfortunately, It seems that you don't have fully
debuging symbols. Can you please at least recompile Assuan with debugging
symbols so that the backtrace includes filenames and line numbers. Thanks!

Also: feel free to add the link to this issue and if it does turn out to be a
problem with GnuPG add any information here. Thanks!

(gdb) backtrace
#0 0xd12727f8 in int_vasprintf () from /opt/freeware/lib/libassuan.a
(libassuan.so.0)
#1 0xd12727a0 in _assuan_vasprintf () from /opt/freeware/lib/libassuan.a
(libassuan.so.0)
#2 0xd1272630 in _assuan_debug () from /opt/freeware/lib/libassuan.a
(libassuan.so.0)
#3 0xd1271398 in assuan_new_ext () from /opt/freeware/lib/libassuan.a
(libassuan.so.0)
#4 0x10004300 in ?? ()
#5 0x10000d08 in ?? ()
#6 0x100001b4 in ?? ()

Thanks for the report. We're not upsteam for KGpg and neither I nor Werner use
Fedora, which makes this issue difficult to debug. Can you please file a bug
report in Fedora's tracker? Thanks.

Hi Neal,

While I'm not keen on intentionally causing you (or others) to have to perform
extra work, you might want to have a quick look at another issue potentially
involving 2.1.15 (only), and which I just filed:

T2048

My guess is that they are unrelated failures, which is why I created the new issue.

I only mention this other issue in case the ultimate root cause is, or turns out
to be, inextricably linked, or intertwined, with this Issue2038.

As always, kindest regards.

The Problem: KGpg fails to automatically start at login on Fedora 22 with KDE.

I have KGpg configured with: Start KGpg automatically at login, selected.

This option is located at:

Configure KGpg, Misc, under the Global Settings tab.

I am running: gpg2 --version = gpg (GnuPG) 2.1.5 + libgcrypt 1.6.3

Following boot, and login, I have verified, using top, that KGpg is not running.

Furthermore, there is no KGpg launch/configuration/encryption icon available in
the System Tray, under Status & Notifications.

If I want to use KGpg, I must manually start KGpg. Following this manual
start, KGpg does indeed begin running, and is assigned a PID, then the
KGpg icon does appear in the Status & Notifications section of the System Tray.

Once manually launched, KGpg does work correctly.

Importantly, note that KGpg does autostart correctly, with a properly functioning
KGpg icon immediately available after login on both of my Gentoo Hardened and
Debian 8 rigs. Each of those operating systems run GnuPG 2.0.6, and both use
KDE with KGpg configured to automatically start at login.

I do not know whether this issue is being caused by 2.1.15, or something
KDE/Fedora did with KDE/Plasma5 in their release of Fed 22.

Any insights are appreciated.

Hi Neal,

Glad to learn you will be investigating.

Yes, it does seem obvious that intentionally rolling out 2.1-x with less
capability than 2.0-x makes little sense.

BTW: If you remove my email address from your most recent post, from a privacy
perspective, I won't mind. ;P

Cheers

$> gdb which gpg-connect-agent
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
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 "powerpc64-ibm-aix6.1.2.0".
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /usr/bin/gpg-connect-agent...(no debugging symbols
found)...done.
(gdb)
Starting program: /usr/bin/gpg-connect-agent 'getinfo version' /bye
[New Thread 1]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1]
0xd12727f8 in int_vasprintf () from /opt/freeware/lib/libassuan.a
(libassuan.so.0)

At Thu, 16 Jul 2015 11:52:04 +0000,
SlipperyCow via BTS wrote:

SlipperyCow <slipperycow@privatdemail.net> added the comment:

Hi Neal,

On Gentoo Hardened, 2.0.26 + libgcrypt 1.5.4 is installed.

On Debian 8, 2.0.26 + libgcrypt 1.6.3 is installed.

GnuPG works on both of those operating systems when using long passphrases.

Did something change in the 2.1.5 code that impacted, or restricted, acceptable
passphrase length?

Hi Neal,

On Gentoo Hardened, 2.0.26 + libgcrypt 1.5.4 is installed.

On Debian 8, 2.0.26 + libgcrypt 1.6.3 is installed.

GnuPG works on both of those operating systems when using long passphrases.

Did something change in the 2.1.5 code that impacted, or restricted, acceptable
passphrase length?

Thanks!

One more question: on the other systems that do work with long passphrases, are
you also using 2.1.5? Thanks.

Hi Neal,

First, thanks for your follow-up. I believe you have understood the problem I
described correctly.

All this information was generated while using Fedora 22.

Per your requests:

I needed to change echo | gpg -s >/dev/null to echo | gpg -su KeyID >/dev/null
to force the use of a Key with a long passphrase.

The result of that test is a success, and in this case I was using a passphrase
which is greater than 700 Bits. Direct copypasta (not Auto-Type) from Keepass
into the terminal, works.

Furthermore, I know gpg is working correctly with long passphrases because, as a
generic example, I can sign and encrypt a file with KeyID#23 for user KeyID#37
and then, decrypt that file with KeyID#37. Therefore, a command like this also
succeeds:

gpg -seu KeyID#23 -r KeyID#37 foo.txt

Both KeyIDs are protected by long passphrases.

Now, moving onto gpg2. As above, I needed to modify echo | gpg2 -s >/dev/null to
echo | gpg2 -su KeyID >/dev/null to force the use of a Key with a long passphrase.

The command, echo | gpg2 -su KeyID >/dev/null, fails on Fedora 22 using pinentry-qt4
in the exact way I originally described. When the command is entered, the pinentry
pop-up, passphrase entry window is generated on your display.

In this case, you must use Keepass's right-click, Auto-Type option/command
(copypasta fails) for the pertinent Key. When Auto-Type completes typing
the 700+ Bit passphrase, tabs (once), and then 'hits' Enter, the error generated in
the pop-up window is:

Passphrase too long (try 2 of 3)

If you try to use Auto-Type a second time, the pop-up disappears, but nothing
happens (a 'visually silent' fail, if you will).

However, following each of these Auto-Type entry failures, the command line
now shows something pinentry does not:

gpg: signing failed: No passphrase given
gpg: signing failed: No passphrase given

This is quite an interesting error message, given that I watched the passphrase
being Auto-Typed, and entered, twice. Again, I've been using Auto-Type for years.

Neal, you also asked for these bits. On my Fedora 22 box, I have:

gpg --version: gpg (GnuPG) 1.4.19
gpg2 --version: gpg (GnuPG) 2.1.5 + libgcrypt 1.6.3
pinentry --version: pinentry-qt4 (pinentry) 0.9.2

Hopefully, this helps you narrow down where, and how, this failure is occurring.

As always, let me know if you need something else.

P.S. I'll fire an email to you with my Public Key in case you have any minor,
or quick, requests. However, of course, I'll need to change OSes first, because
I cannot encrypt any emails with Keys protected by long passphrases on Fed 22! ;-)

Also, compression will likely be removed from future versions of OpenPGP (RFC
4880 bis). There are three justifications. Removing compression simplifies
packet processing, which is good for security. OpenPGP is an encryption
standard not a compression standard and not including it doesn't preclude the
user from compressing the data anyway. It's a security risk, because
"compression provides an oracle for the plaintext" (see [1] and [2]).

[1] http://cryptopals.com/sets/7/challenges/51/
[2] https://www.ietf.org/mail-archive/web/openpgp/current/msg07718.html

Since you have a corefile, you probably have debugging symbols. Could you just
attach gdb and get a backtrace? Thanks!

gdb `which gpg-connect-agent`
run 'getinfo version' /bye

I'm not sure that 208k is much bigger than 196k. What is likely going on is
that gpg is using different compression parameters from zip.

I just tried using the Fedora 22 live cd, but it causes a kernel panic when
booting under qemu. I don't know what the problem is and don't have time right
now to debug it or install a full Fedora system. As such, I'd appreciate any
help that you can give. Thanks!

Closing as requested. Thanks for taking time to bring a potential issue to our
attention!

Sorry, disregard this and close, it was a configuration error on my side…

Sorry, disregard this and close, it was a configuration error on my side (there was
another key in the mix).
This works as expected.

Thanks for your detailed bug report. If I've understood correctly, the long
password problem only occurs on Fedora 22 and not on other systems that you've
tried.

Can you please provide me with a bit more information. Please take enigmail
out of the loop by running:

  echo | gpg -s >/dev/null

and

  echo | gpg2 -s >/dev/null

(assuming gpg and gpg2 are different binaries, which is normally the case).

Then, please tell me the OS, the version of gpg (gpg --version), the version of
pinentry (pinentry --version) and whether you got the error. I'm primarily
interested in Fedora 22, since this is where you observe the error.

Thanks for your help.

Permissions are fine.
Still same issue.

committed to master branch:
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=b3286af36d452fc801be573a057b0838d53a2edd

This shouldn't be a problem. Note: this type of question is better asked on the
gnupg-users mailing list.

Yes, it does. Thanks!