You stated that you deliberately used a self-signed SSL cert instead of
buying one, because, in your own words, "The X.509 system is broken beyond
repair."

That is a political reason, and is has reduced user security. Using non-
working SSL reduces security - you do know that, don't you?

The *reason* security gets "broken beyond repair", is because too many
people change mistakes into "notbug" and never fix stuff.

Bite your tongue, swallow your pride, spend the $3.50 and just buy a
certificate mate.

This conversation is going to get read by other people in future, you decide
next what you want them to think about you.

Some may want such an option, please discuss at gnupg-users and re-open this bug
if the conclusion is that there needs to be a way to ignore the preferred keyserver.

Just a last remark: You have an encrypted connection which protects you from
passive easvesdropping of the password. Securing agains active attacks is much
harder and thus useless. The only thing we need to protect is the password
which in turn is only used as an anti-spam measure. All information in the
tracker are public anyway.

I have not reduced the "security" of anything for political reasons.
This discussion does not belong into a bug tracker - please use gnupg-users
instead. Thanks.

What platform? Did you run ldconfig after installing a library?

I really want to try, but I cannot compile 2.1.2 due to T1862.

In what other ways have you "on purpose" reduced the security of your users
for tin-foil-hat political reasons I wonder?

Buy the cert. It's, like, $3.50 (comodo), or if you really want to splurge,
$49 for unlimited number of domains and SANs and wildcards and whatever else
tickles your fancy (startssl)

Compiling with latest npth instead of latest pth does not change anything.
Without patch = segfault, with patch = works.

I do not think that such an option is useful. Please feel free to discuss at
gnupg-users to get other opinions.

Duplicate of T1644

Okay, I changed your role so that you can comment on T1644.

It is very unlikely that we are going to fix that in 2.0, thus be prepared to
move to 2.1.

That is actually on purpose. The X.509 system is broken beyond repair. It is
just not SECURE. The only thing you get is protection against passive
eavesdropping (if at all).

However, given all these complinats it might be easier to pay for a certificate.
I will consider this but first the tracker needs to be moved to another box.

Wow. I didn't even know that was a thing. What's weirder is --keyserver doesn't
override it. Shouldn't the user be able to override it somehow?

Yes, I understand that keyids are not unique. However, when I ask for the
fingerprint of a key, I likely mean the primary key, not subkeys. People use
keyids (hopefully long, often short), or fingerprints as an identity... and they
always mean of their primary key, not their subkeys. There should be an option
to list only primary keys that match.

Thanks. It might be related to a left overPGP-2 key in the trustdb. I need to
investigate that closer.

gpg --check-sigs --list-options show-keyserver-urls BEB441496300CC3D
[...]
sig!3 BEB441496300CC3D 2011-02-15 Jeremy Kitchen (Systems

   Preferred keyserver: hkp://subkeys.pgp.net/

The key itself specifies preferred keyserver which overrides a standard keyserver.

keyids are not unique. The short keyid of the subkey of the second key matches
the keyid of the first key and thus both are listed.

It is just warning which does not matter if you are using a released tarball.
The next release will support newer autotools and has updated helper files.

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.