I take this because I have a related other improvement in mind.

D304: 668_0001-Make-try-all-secrets-work-for-hidden-recipients.patch

I have also encountered this while testing the --throw-keyids option with 2.1.6.
It seemed to me that the fix is not that hard, so I'm attaching a patch.

Isn't gpgme a part of GnuPG? Anyway, the problem as I understand it is internal
to GnuPG libraries. When a program makes a gpgme_op_decrypt() call to gpgme, it
in turn uses libassuan (and, I am guessing libgpg-error; correct me if I'm
wrong) to eventually inivoke gpg-agent. This process takes up to one second. We
have tested it on SunOS, AIX, and Linux. The delay times are slightly different,
but the common thing is that it only started happening in the versions that use
the agent instead of a callback mechanism for passphrase retrieval.

I don't have a command-line example as our code uses the gpgme API. I could
perhaps create a simplified C program to demonstrate the point if you wish. It
would take me some time to figure out the build options, prepare the keyring and
encrypted files, and to write the actual code, so I am hoping that it is
unnecessary, though.

I also might add, I cleared out the %appdata%\gnupg directory before trying to
import the key. I also tried importing my public key first, then importing
the secret key, with the same result.

You fed gpg with data not in the OpenPGP format. The begin of the data however
is similar to OpenPGP and thus gpg tries to parse it but stops at the first
detected error.

For help please write to one of the mailing lists.

c) Run gpg-agent under gdb
d) Run a modified gpg-agent (rm ~/S.gpg-agent; my-gpg-agent --daemon)
e) Hook into the tty and use pinentry-curses
f) scp ~/.gnupg/private-keys-v1.d/* mybox: and sniff the passphrase.

Thanks for writing this report. I have this annoying problem in mind (and also
known what passphrase to enter) but having a rport is better. Sorry, will take
some more time to fix that.

That is a known problem. I have not yet found the time to fix it. I think
there is another bug report as well.

re 1) ssh-rsa-cert-v01@openssh.com is the certifiate as used by sshd/ssh. The
agent protocols however uses an ssh-rsa-cert-v00@openssh.com format to send the
private key to the agent. We should be easy to support this if it is sufficient
to just get the private key from the ssh-rsa-cert-v00.

re 2) I need to look close on how this is handled by the ssh-agent protocol.

gpg-agent should not look for an ssh file directly because its API is based on
the ssh-agent protocol. Thus a modified ssh is required. I noticed an
ssh-agent object related to card - this needs futher investigations.

so far, the proposed mechanisms for getting at gpg-agent's memory from a peer
process running as the same user are:

a) ptrace (e.g. via /usr/bin/gcore or /usr/bin/strace)
b) /proc/$PID/mem, which is owned by the user and mode 0600

DarkStarSword's patch effectively closes (a) (by rejecting ptrace connections)
and appears on my GNU/Linux system to close (b) as well: /proc/$PID/mem is
root-owned when the patch is applied instead of being user-owned.

Are there other channels for per-process memory access that we should be
thinking about?

I agree with Werner and Neal that the UNIX model is probably insufficient to
close all the holes easily, but i also don't think that's a good reason to avoid
closing those holes we can close.

If there are other ways that another process by the same user can get at the
RAM, please point them out and i'll look into ways to address them too.

In the meantime, i'll also look into ways to facilitate running the process as a
separate user account entirely.

I am closing this.

BTW: I can't share DarkStarSword's fear about prioritizing ease of debugging
over security - I would never do that for a real security problem; Neal and me
both explained why this proposed fix does can't help against an attack.

D128: 666_0003-Avoid-simple-memory-dumps-via-ptrace.patch

I'm going to introduce the prctl(SET_DUMPABLE, 0) change to main in
agent/gpg-agent.c in the debian 2.1.x series as of 2.1.7-1, using the patch i'm
attaching here.

I make no representations that this solves all possible memory leakages, but it
does address one specific and relatively straightforward attack.

As to Werner's legitimate concerns about making debugging harder, there remain
at least two options: ptrace as the superuser, and launching gpg-agent itself
under gdb directly.

If this experiment proves disastrous somehow (i'm not seeing how), we can always
revert the patch.

Glad I was able to help get one bug fixed at least :)

The in-memory encryption will definitely help in this scenario (that is, a
casual attack by e.g. a colleague or another student having a laugh as their
friend left their screen unlocked... real attack - I should know, I've done it,
and had it done to me, as had several of my friends back in uni (to be fair -
that was on Firefox password manager, but it could just as easily have been
gpg-agent)... This is not about stopping a motivated attacker with physical
access to the system as they could always subvert the system in other ways e.g.
adding a shell alias to run a trojaned gpg-agent instead of the real thing,
install a key logger, etc).

I'm still not super happy that a casual attacker could walk away with a core
file containing the encrypted passphrase and the key to decrypt it. What started
as a casual attack for a laugh could later transform into a more serious attack
given that they can hold onto this information indefinitely. I'm not a motivated
attacker, but that would tempt the hell out of me if I was even slightly so
inclined. I should know, because I've been in a similar situation in the past
where I obtained an unshadowed passwd file (through a purely casual attack when
I was looking up a friend's uid and discovered the passwd file was not
shadowed... so of course I made a copy). I could have left it alone, but it
tempted the hell out of me and I ended up running john over it for two straight
weeks (never did much with the result, but that's not the point)!

I would hope that the developers of any security product learns to think like an
attacker.

I must say I am deeply troubled by the priority seeming to be on the ease of
debugging a security product which has the sole purpose of keeping a passphrase
safe. As the saying goes security is always a trade-off, but given that
gpg-agent is a security product and not a word processor, this particular trade
off does not sit right with me. I would expect the development team to have root
access on their own systems, which avoids the issue as the root user can always
attach a debugger with or without this change - is there truly a reason that
they need to attach to a running gpg-agent on a system they don't have root on?
And what about the thousands of gpg-agents running on other systems in the wild
that should never need to attach a debugger (and if they do... sudo)?

The information about FIPS mode and SELinux is good to know, at least for people
running distributions that support and enable them by default. But from what I
can gather FIPS mode is a RHEL only feature (I may be wrong - I'm not all that
familiar with it), and SELinux is still either not enabled, or in permissive
mode in many distributions by default (including Debian and Ubuntu).

As I mentioned in the original report, an alternative way to protect the memory
of gpg-agent is to install it with the setgid bit set (ssh-agent does both the
prctl() and setgid for example - now there's some developers I applaud). Unlike
SELinux and FIPS mode this works in every distribution and has been supported
for donkeys years.

With my tests it works with keyrings when specified using --keyring.

However, gpgv should also work with a keybox by default. This is now
implemented:

trustedkeys.kbx is now the default. If that does not exists gpgv also tries to
use trustedkeys.gpg (keybox or keyring) for backward compatibility. Right there
is a minor backward compatibility problem if a file "trustedkeys.kbx" alread
exists and you migrate to 2.1 - but I do not think that this is a real world
problem.

I am not sure how to to this in gpg and gpgme, thus for now only the gpg-agent part.

Okay, I added a --force option to gpg-agent.

gpg-connect-agent 'DELETE_KEY --force <KEYGRIP>' /bye

Does now do the same as

rm ~/.gnupg/private-keys-v1.d/<KEYGRIP>.key

This identified another bug: To be prepared for FIPS evaluation,
gpg-agent does not store the cached passphrases in the clear but
encrypts them in memory. Right this is security by obscurity but if
we ever have a way to store that key in a secured RAM (e.g. TPM, ARM
TrustZone) we can indeed limit the time a passphrase is available in
the clear to the period it is really needed. This all seems to work
but your tests shows that libassuan does not clear its internal line
buffers so that you can actually find the passphrase in the core
file. I just pushed a fix for this.

IIRC, FIPS mode in Linux inhibits all access to process memory system
wide. Changing this just a for a single user process does not make
much sense.

Further, being able to attach to a running processing is one of the
best debug methods we have. Giving up on this without for a perceived
extra protection is not going to work. There are too many ways to get
the passphrase using other ways. Linux can't protect a user to get
data belonging to him. Iff gpg-agent were a system daemon things
would be different and extra protection would make sense as a
fallback.

Without this I can do gcore pidof gpg-agent and QUITE CLEARLY see my
passphrase in the produced dump:

ian@draal~ [i]> gcore (pidof gpg-agent)
0x00007fb8f8849293 in __select_nocancel () at

../sysdeps/unix/syscall-template.S:81

81      ../sysdeps/unix/syscall-template.S: No such file or directory.
warning: target file /proc/1560/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffce0a12000.
Saved corefile core.1560
0x00007f2dd583c293 in __select_nocancel () at

../sysdeps/unix/syscall-template.S:81

81      ../sysdeps/unix/syscall-template.S: No such file or directory.
warning: target file /proc/1540/cmdline contained unexpected null characters
warning: Memory read failed for corefile section, 8192 bytes at 0x7ffccfbe3000.
Saved corefile core.1540
ian@draal~ [i]> strings core.1560 | grep pass
passwd
This is my ultra secure passphrase - I definitely expect any program that

manages this to take reasonable steps to keep it safe even if I accidentally
leave my screen unlocked one day!

Invalid passphrase; please try again
You need a passphrase to unlock the secret key for user:%0A"test123

<test@test.com>"%0A2048-bit RSA key, ID DE3A7EAB, created 2015-08-06 (main key
ID F459B571)%0A

    SETERROR Invalid passphrase; please try again
    his is my ultra secure passphrase - IQ
    ian@draal~ [i]>

With this one line change I cannot do the above - that's the definition of
reducing the attack surface last time I checked.

You absolutely can still use gdb to debug it - you just have to start it under
gdb as opposed to attaching to an existing process, or attach the debugger as
root. You could also just disable the syscall in a debug build.

The problem is that the same secret key may be used for OpenPGP, S/MIME, Ssh,
and possible other cleints directly accessing gpg-agent.

Thus I am not sure how to best do it. The direct gpg-agent interface of gpgme
could be used to delete a key if we add a --force option to the agent's
DELETE_KEY command.

It does not reduce the attack surface. And yes, it complicates things
because you can't anymore debug the process without changing the code
or using other tricks (aka attack). I have not tested the SELinux
feature for quite some time but gnupg supports SELinux if configured
with --enable-selinux-support. If you want some protection better use
that.

dkg: We disable core dumps for the simple reason that we do not want
to see core files on disk. Disk sectors have a longer lifetime than a
process and a user session - thus avoiding core files is a real world
threat mitigation.

This has since been handled in: T1691
It is fixed in Gpg4win.

So a single syscall to demonstrably reduce the attack surface really complicates
things does it?

News to me.

I agree with you that the standard UNIX model is generally insufficient here.

Perhaps the distros could weigh in with mechanisms to facilitate
secondary-account creation for agents and the like. I've opened
https://bugs.debian.org/794667 about this.

However, i don't think the weak UNIX permissions model is a reason to avoid a
small piece of code like that offered by DarkStarSword below. Closing off one
avenue of attack is still worthwhile, even if other avenues remain. As werner
said, gpg-agent won't create a coredump (even though other avenues of attack are
possible).

Is there something about the complexity of prctl(PR_SET_DUMPABLE, 0); that makes
it undesirable?

dkg: The problem is that the underlying architecture is broken. Unix's stock
permission model is about protecting users from other users, not protecting
processes from other processes. Thus, I don't think it makes any sense to
complicate the code by implementing these effectively useless protections.

FWIW, a widely used practical system that does a much better job at this is
Android. Android runs every program under its own uid. We could do the same
thing with gpg-agent. In fact, this is currently possible with a little help
from ssh. Unfortunately, this requires a fair amount of work by the user to set
up. In particular, the user needs to create a secondary account. It would be
nice if distributions provided a simply way for an unprivileged user to allocate
additional uids, but this is probably a lot of work.

Dup key fixed with commit 4a326d7

commit f05a63b fixes the main problem.
I'll now check why the migration creates a duplicate key.

fwiw, i'd be fine with enabling protection against ptrace for gpg-agent, even if
that doesn't fix all the other ways a process can be attacked from another process.

if there are multiple holes, we should plug the ones we can plug, to increase
the pressure to make the other ones fixable.

Yes they are, the output of `$GNUPGBIN --homedir $GNUPGHOME --with-fingerprint
--with-colons --list-key | grep ^fpr` is identical for both (GNUPGBIN=gpg,
GNUPGHOME=/run/shm/gnupg1) and (GNUPGBIN=gpg2, GNUPGHOME=/run/shm/gnupg2).

Also, the keystores were created with

$ mkdir -m0700 /run/shm/gnupg{1,2}

$ echo 'trust-model always' | tee /run/shm/gnupg1/gpg.conf

/run/shm/gnupg2/gpg.conf

  $ echo no-autostart >>/run/shm/gnupg2/gpg.conf
  $ gpg2 --export | gpg  --homedir /run/shm/gnupg1 --import
  $ gpg2 --export | gpg2 --homedir /run/shm/gnupg2 --import

(Each keystore currently contains 1291 public keys and 235302 signatures, 161385
of which from unknown signers.)

Actually 2.1.6 on the keybox does about 4x more read(2) than 1.4.19 or 2.1.6 on
the legacy format.
Here are some figures using the i7:

$ strace -co /tmp/sigs_gpg_gnupg1 gpg --homedir /run/shm/gnupg1 --with-colons

--list-sigs >/dev/null

$ strace -co /tmp/sigs_gpg2_gnupg1 gpg2 --homedir /run/shm/gnupg1

--with-colons --list-sigs >/dev/null

$ strace -co /tmp/sigs_gpg2_gnupg2 gpg2 --homedir /run/shm/gnupg2

--with-colons --list-sigs >/dev/null

  $ head -5 /tmp/sigs_*
  ==> /tmp/sigs_gpg_gnupg1 <==
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   71.05    0.010748           0   7480899           read
   15.64    0.002366           0   2233564           getrusage
   12.94    0.001958           0   2233564           clock_gettime

  ==> /tmp/sigs_gpg2_gnupg1 <==
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   99.92    0.010204           0   7480899           read
    0.04    0.000004           0      4608           write
    0.04    0.000004           0     20438           lseek

  ==> /tmp/sigs_gpg2_gnupg2 <==
  % time     seconds  usecs/call     calls    errors syscall
  ------ ----------- ----------- --------- --------- ----------------
   99.94    1.724001           0  29610764           read
    0.02    0.000386           0     15307         9 open
    0.02    0.000376           0     15290           munmap

Interestingly, with --list-keys 2.1.6 is actually faster on /run/shm/gnupg2:

  $ time gpg --homedir /run/shm/gnupg1 --with-colons --list-keys >/dev/null
  0:02.01 (1.99 user, 0.02 sys)  11004k maxres
  $ time gpg2 --homedir /run/shm/gnupg1 --with-colons --list-keys >/dev/null
  0:02.03 (2.01 user, 0.02 sys)  11456k maxres
  $ time gpg2 --homedir /run/shm/gnupg2 --with-colons --list-keys >/dev/null
  0:00.60 (0.58 user, 0.02 sys)  16568k maxres

It also does about 10x less read(2):

$ head -5 /tmp/keys*

==> /tmp/keys_gpg2_gnupg1 <==

% time     seconds  usecs/call     calls    errors syscall

------ ----------- ----------- --------- --------- ----------------

100.00    0.000004           0     21011           read

  0.00    0.000000           0       166           write

  0.00    0.000000           0        20         3 open



==> /tmp/keys_gpg2_gnupg2 <==

% time     seconds  usecs/call     calls    errors syscall

------ ----------- ----------- --------- --------- ----------------

  0.00    0.000000           0      2036           read

  0.00    0.000000           0       166           write

  0.00    0.000000           0        19         3 open

Each test for a passphrase takes about 100ms - thus you have your rate limit.

Because the majority of humans are not able to remember such a passphrase and
thus most will use some passphrase manager to remember that. In that case you
can use a full-entropy key directly (cf. T2038 (wk on Jul 30 2015, 07:59 AM / Roundup)).

Sure it does syscalls because it reads the keybox file for each signature. The
order of the keys in the keybox can make a big difference when checksing
signatures. Arge the keys store in the same order? "gpg -k" walks the
keyring/keybox sequentially.

Thanks for trying to fix that bug, Werner! However, while your patch does
indeed make 2.1.6 quite a bit faster than 2.1.5, it's still much much slower
than the venarable 1.4.19. And since with a keybox 2.1.x spends most of its
time doing syscalls, I believe there is something odd in the way it reads
keyboxes hence I'm reopening the issue.

With an x60s (i686, 2x Core Duo L2400 @ 1.66GHz, 3GiB DDR2 PC2-5300):

  $ time gpg --homedir /run/shm/gnupg1 --list-sigs >/dev/null
  2:16.41 (91.60 user, 43.06 sys)  9444k maxres
  $ time gpg2 --homedir /run/shm/gnupg1 --list-sigs >/dev/null
  2:14.45 (97.77 user, 35.41 sys)  10364k maxres
  $ time gpg2 --homedir /run/shm/gnupg2 --list-sigs >/dev/null
  19:40.61 (80.14 user, 1088.58 sys)  15016k maxres

With a desktop (x86_64, 4x Core i7-4770S @ 3.1GHz, 16GiB DDR3 PC3-12800):

  $ time gpg --homedir /run/shm/gnupg1 --list-sigs >/dev/null
  0:30.74 (24.32 user, 6.40 sys)  11700k maxres
  $ time gpg2 --homedir /run/shm/gnupg1 --list-sigs >/dev/null
  0:26.34 (20.24 user, 6.08 sys)  13132k maxres
  $ time gpg2 --homedir /run/shm/gnupg2 --list-sigs >/dev/null
  2:23.97 (14.39 user, 129.52 sys)  18800k maxres

(On both machines, '/run/shm' is mounted in memory. '/run/shm/gnupg1' contains a
keyring in legacy format, while '/run/shm/gnupg2' contains the same keyring in
keybox format.)

So on the fast machine, --list-sigs is still 5x slower on a keybox. Note the
proportion of the execution spent in kernel mode: 93% on the L2400, 90% on the
i7! (Vs. 26% and 23% with a legacy .gpg format.) I have also a hunch that this
might be the reason why updating the trustdb takes that long with 2.1.x and a
keybox.

At Fri, 31 Jul 2015 10:27:04 +0000,
Werner Koch via BTS wrote:

Werner Koch <wk@gnupg.org> added the comment:

Despite that the use of these 100 characters is not a proper way to protect a
private key, they may exceed the 255 characters if most of them are non-ASCII
and non-Latin-1. Most characters of the latter are endoded with just 2 bytes in
UTF-8.

Despite that the use of these 100 characters is not a proper way to protect a
private key, they may exceed the 255 characters if most of them are non-ASCII
and non-Latin-1. Most characters of the latter are endoded with just 2 bytes in
UTF-8.

To test whether there is a problem with the key signature verifcation test, you
may run your test cases again with the added option --no-sig-cache. These
things are not easy to replicate because they depend on the keys in your keyring
and your ownertrust settings.

gpg2 is unusable under jessie. Just browsing my inbox in icedove/thunderbird
causes the following:

top - 11:08:34 up 17 days, 35 min, 7 users, load average: 4.47, 3.24, 1.93
Tasks: 243 total, 4 running, 239 sleeping, 0 stopped, 0 zombie
%Cpu(s): 60.9 us, 16.3 sy, 0.0 ni, 21.7 id, 1.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 8072496 total, 7827000 used, 245496 free, 117576 buffers
KiB Swap: 7688188 total, 1291184 used, 6397004 free. 1675144 cached Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

3420 agallag+ 20 0 78616 57736 3572 R 99.5 0.7 6:06.75 gpg2

3494 agallag+ 20 0 33040 11912 3532 R 99.5 0.1 4:52.95 gpg2

3424 agallag+ 20 0 31940 10796 3468 R 99.2 0.1 3:31.33 gpg2

8743 agallag+ 20 0 5129560 2.326g 44372 S 5.3 30.2 1262:07 iceweasel

7743 agallag+ 20 0 1898320 198764 26908 S 2.3 2.5 225:11.77 gnome-shell

3407 root 20 0 0 0 0 S 0.7 0.0 0:00.50 kworker/3:0

4344 jira 20 0 3547040 581920 5216 S 0.7 7.2 84:02.57 java

3610 agallag+ 20 0 25944 3168 2428 R 0.3 0.0 0:00.01 top

3718 root 20 0 364320 63932 41096 S 0.3 0.8 110:25.72 Xorg

5899 agallag+ 20 0 2750304 86372 13620 S 0.3 1.1 2:40.06 dropbox

7858 agallag+ 20 0 419240 25884 9216 S 0.3 0.3 12:40.70
gnome-terminal-
10159 agallag+ 20 0 2155424 602372 46804 S 0.3 7.5 116:15.04 icedove

                                                
    1 root      20   0   15484   1084   1048 S   0.0  0.0   0:06.36 init

I can't use gpg1 in the meantime because I have a smartcard.

Werner: I think there is a bit of confusion. The suggestion is not to up the
998 character lmiit, but the pinentry-qt limit of 256. Rereading my note that
was probably not clear.

Also, the long password that SlipperyCow is talking about is about 100 characters.

I do not see a reason to support useless long passphrases.

Normal humans are not able to remember such a long passphrase. If you want to
use a really stong passphrase you have to use a generated anyway. A generated
passphrase however has an easy to compute entropy and thus a 256 byte limit is
more than sufficent for a 32 byte (=256 bit) key.

neal: We can't easily lift the 998 byte limit. Also note that a passphrase
character might in theorie be up to 6 byte.

Right. SHA-256 never worked because the CSR anyway indicated SHA-1 but signed
using SHA-256.

Note that the signing of a CSR is only there to indicate that one own the
private key. The resulting certificate may use any signing algorithm on the
discretion of the CA.

Does this mean it would also not be possible to generate a CSR with SHA256 as
hash algo with 2.0 at all? I think I've tested this some time ago and it worked
but that might have been 2.1

I'd like to see this fixed as the change was part of the NEWS for 2.0.28 and do
we really want to have a NEWS entry like "The default hash algo for a CSR is now
SHA-1 again because we failed to get SHA-256 working"? :-p

The Assuan protocol limits the length to 998 characters. But, sure,
we can up the limit.

Neal: Pinentry-qt Uses a hardcoded magic Number of 256 characters
(pinentrydialog.cpp:140)

So with pinentry-qt you can't enter longer passphrases. I don't know why. Maybe
we want to change that?

To be clear: pinentry passes the passphrase back to GPG Agent using Assuan.
Assuan has a line limit length of 1000 characters. This means that passwords
upto 998 characters should be okay. Can you please tell me how many characters
long your password is? Thanks!

Hi,

I just tried:

  echo | gpg2 -s > /dev/null

using an 80 character password. This correctly signed the message. I used
GnuPG from git and pinentry from git. I configured gpg-agent to use
pinentry-qt4. So unfortunately, I can't reproduce the problem (yet).

Neal

Note: in 2.1 (master) this is correctly implemented.

I had to revert the CSR part of the patch. Done with commit 35d3ced.

There a couple of problems with using aritrary hash algorithm in gpgsm. We
better solve that in master first and then decide whether it makes sense to
backport.

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.

OK, here are the outputs:

  $ /usr/bin/gpgme-config --version
  1.4.3
  $ ./gpgme-version
  Version from header: 1.4.3 (0x010403)
  Version from binary: 1.4.3
  Copyright blurb ...:

  This is GPGME 1.4.3 - The GnuPG Made Easy library
  Copyright (C) 2000 Werner Koch
  Copyright (C) 2001--2013 g10 Code GmbH

  (d788c35 2014-12-06T04:06+0000)

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.

The SO number is unfortunately not helpful to show the GPGME version.

/usr/bin/gpgme-config --version

displays the gpgme version but that assumes that the shared library
matches the version of the installed development files. You may copy

#include <stdio.h>
#include <gpgme.h>

int
main (void)
{

  printf ("Version from header: %s (0x%06x)\n",
          GPGME_VERSION, GPGME_VERSION_NUMBER);
  printf ("Version from binary: %s\n", gpgme_check_version (NULL));
  printf ("Copyright blurb ...:%s\n", gpgme_check_version ("\x01\x01"));

  return 0;

}

into a file gpgme-version.c and run

  cc gpgme-version.c -o gpgme-version $(gpgme-config --cflags --libs)
  ./gpgme-version

to display the real version info.

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.

Solution is fine for me from a usability point of view.

For other users, it is not fine because they will first have to find this
solution, which probably will not happen before having fallen into the pit. So I
would prefer a changed default behavior.

I will try to convince the authors of the OpenPGP standard to remove some of the
complexity of the standard as well as the resulting issues.

GnuPG version is 1.4.19, as reported by gpg --version, but gpg2 is, in fact, also installed:

  $ gpg2 --version
  gpg (GnuPG) 2.1.4
  libgcrypt 1.6.3
  ...

We have seen this problem on various OSs, but in this particular case it is Fedora 22. And we always install GnuPG from package
managers.

Here are all the gpgme files I see:

$ rpm -ql gpgme | grep \.so

/usr/lib64/libgpgme-pthread.so.11

/usr/lib64/libgpgme-pthread.so.11.11.0

/usr/lib64/libgpgme.so.11

/usr/lib64/libgpgme.so.11.11.0

So your solution is fine and produces the same result as a new option. Okay to
close?