On 6 November, there was finally some movement on the 22 July Bug I filed at:

https://bugzilla.redhat.com/show_bug.cgi?id=1245732

Rex Dieter provided the underlying explanation of the KGpg autostart failure on
Fedora 22 (or newer) systems:

He stated:

"Simple reason is that plasma5 doesn't support kde4 apps' use of
X-KDE-Autostart-condition"

Note: Rex is also developing/testing a patch to address this plasma5
shortcoming for Fed 22 systems.

Importantly, and as I had suspected and alluded to, this plasma5 lack of support
explains why the KGpp failure to autostart occured *only* on my Fed 22 systems,
and did not impact any of the other KDE operating systems I use.

I have upgraded all my Fed 22 systems to Fed 23, where the KGpg autostart
currently continues to persist. I have documented the workaround in the Bug
report linked above for anyone impacted. This workaround also works in Fed 23.

Hopefully, this issue will be fully resolved in the next Fedora-approved release
of KGpg.

I laughed when I first read aheinecke's comments, at least right up until the
moment the gravity of the 'unmaintained upstream' hit me!

The Bug I filed on 22 July at: https://bugzilla.redhat.com/show_bug.cgi?id=1245732

has gone exactly nowhere, in a hurry, despite being assigned to Ngo Than.

In any event, another Fedora Forum user and I tracked down the root cause ourselves.

I can confirm this KGpg failure to autostart is *NOT* in any way related to GnuPG.

I have already documented how to cause, and how to avoid, this KGpg autostart
failure in this thread: http://forums.fedoraforum.org/showthread.php?t=305604

Hint: If you are interested, read page 2 of ^that thread first, for a summary,
and a reproducible testing procedure.

aheinecke: Kleopatra was, and is, a 'thing' of beauty! ;-3

Hi Werner,

Fixed in 2.1.8 INDEED!!

I know this to be true as the 'Passphrase too long' error still appears when
running gpg2 on a fully updated Fed 22 system. The latest GnuPG(2) package in
Fedora's repos is: gnupg2-2.1.7-1.fc22.x86_64. When that package is installed:

gpg2 --version

of course, reports: gpg (GnuPG) 2.1.7.

As I originally noted in this bug report, this 'Passphrase too long' error only
appears on my Fedora 22 systems. Therefore, Fed 22 is the operating system I
used to install the required libraries and then compile 2.1.8 from its source
code.

Following appropriate modifications to my ~/.bash_profile

gpg2 --version

now correctly reports: gpg (GnuPG) 2.1.8

Now when running TBird, Enigmail and Keepass2, gpg2 and pinetry-qt4 can now
accept very lengthy passphrases, flawlessly!

I don't know what the maximum passphrase insertion length limit is from a
Keepass2 Auto-Type perspective, but I am happy to report that GnuPG 2.1.8 can
easily handle Keepass2 generated passphrases significantly longer than 750 Bits.

Absolutely great work done here Werner!

Thank you very much Werner and Neal. I very much appreciate your sustained
attention to this now SOLVED matter.

BTW: If either of you have further input, or queries, on the passphrase entropy
topic, I would be happy to discuss these matters with Dominik Reichl who is the
developer behind Keepass - and all of it variants. I have contacted Dominik on
several Keepass issues. He is both highly intelligent and responsive.

Given that Keepass has a large user base across many operating systems, perhaps
a frank discussion, and optimization, of lengthy GnuPG passphrases in general
would be beneficial to a large population of security minded Windows and Linux
users.

Hi Neal,

A minor heads up.

I have appended the following to KGpg Failure to AutoStart bug report in the
hope it allows the devs to think about the nature of this problem's root cause
from a broader perspective:

Additionally, note re: the failure of KGpg to AutoStart:

All of the testing I've described in this bug report, and on the Fedora Forum
link, was performed using a native Fed 22 system installed on a HDD. On this
HDD-based system, I had previously run Fed 21, and used fedup to arrive at Fed 22.

However, I also run Fed 22 as a Guest OS in both VBox and KVM. Installation of
both of these virtual Guests was accomplished using the Fed 22 KDE Spin *.iso.

IIRC, when Fed 22 is first cleanly installed from the *.iso, the gpg2 version
installed is: 2.1.14. After the first: dnf upgrade is performed, gpg2 version
2.1.15 gets pulled in.

Despite these differences, in all three of my Fed 22 installations, KGpg fails
to AutoStart, despite being enabled.

Hi Neal,

Some positive progress to report. A workaround to brute force KGpg to AutoStart
on Fed 22 has been identified in the Fedora Forum where I've been working this
issue.

I have already appended this information to the official bug report in the hope
it helps the devs identify the underlying root cause.

I copy the workaround here so other users of this site and Fed 22 have a process
they can try if desired.

As a workaround to KGpg's failure to AutoStart, this brute force method works on
my Fed 22/KDE system:

1. Manually start kgpg from Konsole:

$ kgpg

2. Ensure ~/.config/autostart is empty. My autostart directory contained one

file , so I did:

mv /home/<username>/.config/autostart/kgpg.desktop /home/<username>

3. Copy the default startfile to the local user's autostart folder to override

defaults:

cp /usr/share/autostart/kgpg.desktop /home/<username>/.config/autostart/

4. Edit the ".config/autostart/kgpg.desktop" file by setting autostart to "true"

(from it's default value of 'false")

X-KDE-autostart-condition=kgpgrc:User Interface:AutoStart:true

5. Save, Close, Logout

6. Following Login, note that KGpg is 'autostarted'. This means the KGpg icon is

available in the System Tray, under Status & Notifications, and KGpg has been
assigned a PID, and is running. Clicking on the KGpg icon shows that all KGpg
functions work correctly.

This brute force method is also known to survive subsequent logouts - logins,
and reboots.

Hi Neal,

I have spent several days debugging this AutoStart failure within the Fedora
Forum. However, none of that effort has yielded any useful information.

Therefore, I have filed a bug report on Fedora's bug tracker covering this
topic, available here:

https://bugzilla.redhat.com/show_bug.cgi?id=1245732

I will let you know the outcome.

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.

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

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!

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! ;-)