Download the page.
gpg -import the downloaded file.
Or copy and paste from the <bre> block.

I consider this a question and not a bug. Please post it again to the
gnupg-users@gnupg.org mailing-list. No need to subscribe; we have moderators to
let it through)

Sorry, I do not understand yourt point.

Sure, FPT is clear and not authenticated. Instead of providing a not very
secure HTTPS access to the files we provide signatures for all source files
which are way more secure than the X.509 infrastructure.

It is in fact reasonsbale to ask to use an existing gpg to verify a signature.
gpg is a base tool for almost free OS distributions for about 15 years.

If you need to fallback to SHA-1 checksum, you may take them from the
announcement or from https://gnupg.org/download/integrity_check.html they are at
the bottom of the page. Only the current versions are listed, though.

I have verified that the bug have been solved in version 2.2.3. Thank you very much.

Posted to the list, though not as a subscriber (so it'll need to be approved).

I apologize if I jumped the gun by posting here first - given that my question
was effectively "is this a bug?" (and that I was expecting the answer to be
"yes"), I was erring on the side of caution.

Here's the output:

% gpg -K 1F38684E
% gpg -K 1F38684E
gpg: Oops: keyid_from_fingerprint: no pubkey
sec dsa1024/46B1EFE1 1999-07-05
uid [ultimate] Neil W Rickert <rickert@cs.niu.edu>
ssb elg2048/1F38684E 1999-07-05

% gpg --with-keygrip -k 1F38684E
gpg: Oops: keyid_from_fingerprint: no pubkey
pub dsa1024/46B1EFE1 1999-07-05

Keygrip = AD607F40378A7ADBC06212C08554174AB7A02B0D

uid [ultimate] Neil W Rickert <rickert@cs.niu.edu>
sub elg2048/1F38684E 1999-07-05

Keygrip = 007FC4C272831E165FDC61E9B078E566D7F472A3

Files exist for both keygrips in that output.

You are right. Due to the first condition the second evaluates to (0==1). I
need to check whether thsi used inside libgcrypt.

What a pity that I released 1.6.3 without noticing this bug. ("typo" falsely
made be believe a doc problem). Sorry.

Does

gpg -K  1F38684E

list this key? If not please do

gpg --with-keygrip -k 1F38684E

and check that there is a file named after the kegrip below
~/.gnupg/private-keys-v1.d/

Well, this sounds more like a question than a bug. Can you please post it to
gnupg-devel?

With that patch:
gpg --list-keys rickert

that now works. However, I am still unable to decrypt. When attempting to open

kdewallet, I get the message:

Error when attempting to decrypt the wallet kdewallet using GPG. If you're using
a SmartCard, please ensure it's inserted then try again.

GPG error was Decryption failed

If I try to decrypt a file at the command line, I get:

gpg: encrypted with 2048-bit ELG key, ID 1F38684E, created 1999-07-05

"Neil W Rickert <rickert@cs.niu.edu>"
gpg: decryption failed: No secret key

However, using the same keyring, this all works with opensuse 13.2 (gpg 2.0.26),
so the secret key is there. The file uses the same key as kdewallet.

This issue seems to be gone with gnupg 2.1.2. Thanks for the fix :)

I could attach some screen shots if that may be of any help.

Back ported to 1.4 (commit 27d7addccf782d5cb0084cb17522d712d4a6d6b)

Fixed in all branches.

Thank. I was not sure about this. Thus I need to re-use the passphrase for
subkey generation (this is a bit complicated but reuidred to remove this
regression).

D285: 559_0001-gpg-Skip-legacy-keys-while-searching-keyrings.patch

The code to skip the old keys is getting quite complex for the only reason to
allow reporting the use of such keys during import.

Please try the attached patch.

In the last non modern version (i downgraded) after the 2.1.2 problem, 2.0.27,
when i generated a new subkey, the only passphrase asked was to unlock the private
key, it never prompted me for another passphrase for the subkey.

So you mean gpg should use the passphrase of the main key for the new subkey as
well, right?

This could be done but it won't allow to use a different passphrase for the
subkey. If that is a regression from 2.0 this should be considered a bug, else
a a "whish".

Fixed. Thanks.

Yes it asks for the passphrase to unlock the keyring, nut when i want to generate
a key, it asks me for the passphrase to unlock the keyring which i provide, then
it follows up with a "enter a new passphrase" dialog. If i cancel said dialog then
it does not allow me to generate and add the key.

Sure it asks for a passphrase when adding a subkey. The passphrase is required
to a) protect the passphrase and b) to create a key-binding signature.

I might have not fully understood your report. In that case please describe it
again step by step.

D286: 558_gnupg-2.1.2-dns-cert.patch

After trying some more, I found out some things.

I just have to run "gpg revoke.asc", without any options.

But then, the reason text that I entered when generating the revocation
certificate is not shown. Nor is the numeric reason.

gpg: standalone signature of class 0x20
gpg: Signature made 02/22/15 15:46:23 Eur using DSA key ID BACCF5EE
gpg: standalone revocation - use "gpg --import" to apply

And I dont understand what “class 0x20” means.

How much time would it take to migrate to QT5?

Thanks, fixed in 2.1.2. (I had to run --edit-key and --check-trustdb first.)

Can you please try with 2.1.2 ?

Fixed with commit 0c3d764.
Should be backported to 1.4.

We already have that "confirm" flag for ssh and thus adding code to use it for
the extra-socket feature should be easy. The open question is how to disable
this feature on a per key base. A ~/.gnupg/confirmcontrol or similar file could
be used to record those keys which do not need confirmation or if persistance is
not required a checkbox in pinentry could be used to show the confirmation
dialog only once per session.

D283: 555_0001-dirmngr-Clean-up-spawned-dirmngr_ldap-processes.patch

This problem is due to ldap_wrapper creating processes with gnupg_spawn_process
but while gnupg_spawn_process states that you have to call gnupg_wait_process
and gnupg_release_process afterwards this is not done in the ldap_wrapper.

Sometimes release is called but never wait to get the exit status of the spawned
process and remove the zombie.

If release is not called this will also leak a handle on Windows.

Attached Patch moves the process cleanup in it's own function and calls that
function from where the process should be terminated and cleaned up.

My test for this:
export GNUPGHOME=$(mktemp -d)
echo "11:B9:1B:31:EE:09:E0:84:4D:25:4E:58:7A:65:CE:51:84:F3:6B:70 S" >
$GNUPGHOME/trustlist.txt
gpgsm --verify signed-smime-test.asc

D284: 554_avoid-crash-with-zero-length-DIR.txt

Here is a screen shot of the error message.

Here is a screen shot of the certificate chain.

Back ported to 2.0 (commit 2b2adb85948ce2c7db727ebc0c99e8ad2c29bf5f)