Just checked 2.4.1 and looks like now everything is OK.

Thanks werner. That helps us to know that such test failure is not a deep issue that would push us to not deliver this version of gnupg on AIX.

With the next release you will get only a warning:

gnupg-2.2/common/t-sexputil.c:467: test 0 failed: Unknown elliptic curve - ignored
This is likely due to a patched version of Libgcrypt with removed support for Brainpool curves

Sorry for the expired certificate.

Fix: "I Know so few about gnupg, thus I'm not sure I COULD add test cases, probably not. "

Hi,
The site now shows: "NET::ERR_CERT_DATE_INVALID" and I have a limited access to the web page.
Thanks for you explanation. However, I now so few about gnupg, thus I'm not sure I cannot add test cases, probably not. I'll see later if we have to provide on AIX a behavior different than the one of RedHat. Meanwhile, about your last proposal, yes it would be very useful to detect the case, print a warning, and skip the test. That would be helpful. Moreover, if the test deals with smartcards, we do not have on AIX, thus this test is very probably not useful in our environment.

The thing is that I added a test for a new function which uses standard curves of Libgcrypt. But here we are again at the RedHat mess: They support the NIST curves but they removed support for Brainpool curves. Both are very similiar curves just different parameters. Brainpool is just in Europe out of fear that the NIST curves are rigged by the the NSA. Now, why RedHat removed Brainpool is probably just a legal dept thing who didn't have a clue. The tin foil hats probably see a different reason.

• a patch change within scd/apdu.c dealing with a call of: pcsc_connect() since code has changed between the 2 versions: may this be the cause of the failure? (Edited: hummm this patch seems no more required. And I have the same failure without it).

Hi Werner,

Supported curves should be listed by

gpg --list-config --with-colons curve

I am not sure about Fedora, but RedHat used to remove ECC support from Libgcrypt; GnuPG requires these curves. As long as you don't use ECC you things will work despite of this failed test. The test is new to check and does not anticipate a broken Libgcrypt.

Reported.

You may.. Comments were relevant. Bye.

FWIW, the GTK and QT pinentries do have a qualitybar. However is is only enabled:

In T4809#131931, @werner wrote:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

@Rycky_Tigg cases 1, 2, and 3 that you document here each show the behavior that i would expect from pinentry-gnome3, given the definition of its Assuan-based API and its use of gcr-prompter. (i'm assuming that in case 3 the user just waited longer than the allowed timeout)

"more specific about what you think is wrong"; From https://bugs.kde.org/show_bug.cgi?id=412569 copied)/pasted:

BTW, the qualitybar is not shown by default, only if you configure sme of the extra password checks. We may even remove it completely because it leads to wrong assumption on why a passphrase is required.

pinentry-gnome uses gcr's gcr_prompt_set_password_new to prompt for a new password, and ignores the SETQUALITYBAR assuan command.

It seems that gnome-keyring-daemon has some incompatible changes which breaks that version of pinentry-gnome. Or GKR has not been setup properly. I'd suggest to use pinentry-gtk until folks with knowledge about Gnome folks have figured out what is going wrong.

Hey. As reference – Complete set of features while run in Windows.

Please describe which features are missing.

I cannot do that because all listed above packages are my own products.
Fedora is not execution test suites in more than 90% of all packages so they are not aware of most of the issues exposed by test suites.
Please focus on possible causes of above tests.
I'm opened on any suggestions to make additional diagnostics.

Thanks. You may want to ask on the mailing list gnupg-users to see whether someone else has had problems building on rawhide. Right now we do not have the time for individual support and thus I unfortunately need to prioritize this bug report down.

GnuPG 1.4 is only for old features. New features are only supported by GnuPG 2.2.

I would suggest to close this as won't fix.

Please use GnuPG 2 (2.0 or 2.1) for using smartcard/token.
smartcard support in GnuPG 1.4 is way old and only supports shorter key length.

I would suggest to add

gpgconf --launch gpg-agent
GPG_AGENT_INFO="$(gpgconf --list-dirs agent-socket):-1:1"
export GPG_AGENT_INFO

to your startup script. This starts gpg-agent and sets the correct socket name
into the envar.

Thanks for testing.

I've made new container and can't repeat the bug. gpgme
components got updated in Fedora.

Ok, there are no significant patches on top of pygpgme. Note that pygpgme is not really
maintained, and that we neither develop nor support pygpgme. But seeing that dnf is important to
Fedora, let's figure this out.

It would be nice if you could try to reproduce the problem without pygpgme though, just to make a
more minimal test case. I see the exception is thrown during some import. This is how I strace
gnupg to see what ioctls it is issuing:

% strace -eioctl g10/gpg --import ../tests/openpgp/samplekeys/ecc-sample-1-pub.asc
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: key 0BA52DF0BAA59D9C: public key "ec_dsa_dh_256 <openpgp@brainhub.org>" imported

• SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=26716, si_uid=1000, si_status=0,

si_utime=0, si_stime=0} ---
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon
echo ...}) = 0
gpg: Total number processed: 1
gpg: imported: 1
+++ exited with 0 +++

Note that if you try to strace your gpgme-based application, you need to pass '-f' to strace to
follow forks.

I have grepped through gpgme and gnupg, and it looks like gnupg is only doing ioctls to terminals,
so maybe your container setup is doing something funny to terminals. But let's see what the strace
shows.

Here is the info about Fedora patches
https://www.rpmfind.net/linux/RPM/fedora/secondary/devel/rawhide/src/p/pygpgme-0.3-15.fc24.src.html

On Wed, Jul 27, 2016 at 1:24 PM, Justus Winter via BTS
<gnupg@bugs.g10code.com> wrote:

I see that you are using pygpgme, is that correct?If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?

Thanks for the report.

I see that you are using pygpgme, is that correct? If so, which version, and are
there significant patches applied in the Fedora package? And can you please tell
me what version of libgpgme you are using?

Let's try to figure out which ioctl fails. Could you try to strace this process?

I'm closing this as Werner think it is a problem with Fedora and the original
reporter hasn't suggested this is not the case.

For the record Rolf Eike Beer still maintains KGpg (I was not aware of this when
i wrote T2048 (aheinecke on Aug 28 2015, 10:54 PM / Roundup))
And he is planning to port it to Qt5.
See: https://mail.kde.org/pipermail/kde-community/2015q3/001651.html

Please leave this issue closed here. This bug either belongs in the Fedora
Bugtracker or in KDE's bugtracker.

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.

The main complaint was fixed in 2b27acc and the program was marked as deprecated
in the documentation.

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

Based on aheinecke's comments I'm closing this.

Kgpg is unmaintained upstream (meaning KDE) Afaik it does not work with gnupg 2.1

We (talking as a kdepim developer here) are currently in the process of removing
libkgpg dependencies in the hope to remove Kgpg altogether. You should use
Kleopatra and nag the Kleopatra developers (me) about features of KGpgp you will
miss in Kleopatra.

This bug has nothing to do with Gpg and should be filed on bugs.kde.org against
kgpg (but as I said it's unmaintained so you probably should not bother)

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.

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.

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.

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!

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.

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.

That might be possible. However outstarting gpg-agent won't be implemented for 1.4.

On Mon, May 18, 2015 at 10:37:08AM +0000, Werner Koch via BTS wrote:

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Exactly this thing I reported as a workaound. I'd like to see working gpg
without setting the GPG_AGENT_INFO variable before.

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Confirmed that this is fixed in GnuPG in 2.0.25. In the external reference (the
bugzilla at RedHat), it's also closed already.
In the SCM (http://pkgs.fedoraproject.org/cgit/gnupg2.git), it's
1f6281e091d124170238821e7b9150ab56ff1195 which
removed the patch.

and for 1.4

Fixed for 2.0.

This is already known and has been discussed at gnupg-devel -users. This is
indeed a regression which needs to be fixed. The import filter does only check
the primary key and as soon as you downlaod via a subkey id the key is rejected.

It is on my short list.

commit 045c979 has the patch to be released with 2.0.25.

The gnupg version mentioned in T1402 (aheinecke on Jun 25 2014, 03:48 PM / Roundup) should be 2.0.22 and not 2.0.18

I can confirm the problem described in the redhat bug still exists. Ran into it
on ubuntu 14.4 with gnupg 2.0.18 (with use-agent in the gpg config).

gpgsm --import <cert> failed with decryption failed without opening pinentry.
But after unsetting GPG_AGENT_INFO it worked.

Is it just me, or are both of my messages truncated to a single line?!

This is in no way specific to Kleopatra (the KDE certificate manager), gpgsm --

KDE's Kontact has been developed along with GnuPG, thus I wonder why you have
this problem. Can you please explain the problem a bit more detailed?