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)
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.
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
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: 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).
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".
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.
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.
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.
Back ported to 2.0 (commit 2b2adb85948ce2c7db727ebc0c99e8ad2c29bf5f)
To reproduce using version 2.0.26 (on Windows):
gpg.conf, without any other keyserver entries:
keyserver hkp://invalid.gnupg.net
This should report that no key has been found. What it *should* report is that
there was a communication problem with the servier.
keyserver hkp://keys.gnupg.net
The application will with the message that it is sending the key to
invalid.gnupg.net, wnen in fact it is not
Good point. I added your suggestion to master.
This will eventually be done but not right now. I keep this bug report as a
reminder.
I granted you permissions to edit other bug reports. However, this patch is not
required.
Nope. See my comments at
https://lists.gnupg.org/pipermail/gnupg-users/2015-February/052401.html
master (2.1) already has limits for such cases and would thus return better
error message. Those will be backported to 1.4 and 2.0. However, for 2.1 your
test case does not work because PGP-2 formats are not anymore supported in 2.1.
I can't repeat that with the current version from the GIT repositories. Can you
please give an example best using --recv-key.
Thanks for the new test vector. This has already been fixed in master and those
fixes will be ported back to 2.0 and 1.4.
In general I would suggest to use at least the latest released version or even
better the respective GIT HEAD for fuzzing work.
Here is the latter half of the output of --card-status in it's entirety...
The URL is listed, as for the signature key, that is the crux of the
problem... it shouldn't care about what the fingerprint of the signature key
when retrieving the public key when the signature key is a subkey as you
can't retrieve just the public key of the subkey, you need to retrieve the
public key of the master key that contains that subkey.
Note below how key 757C0180 is the master key and in the error message in
the op it is looking for AEB99527 which is the signing subkey.
Name of cardholder: John Tennyson
Language prefs ...: en
Sex ..............: male
URL of public key :
https://gist.githubusercontent.com/aelana/0cde322d66206ea5fb90/raw/1cc31e99f
bdb5a75e4104fe597794ec3dccd6bc4/gistfile1.txt
Login data .......: elfindreams
Signature PIN ....: forced
Key attributes ...: 2048R 2048R 2048R
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: 85D5 A0DA 4EC2 B038 128F 9D88 4791 2162 AEB9 9527
created ....: 2015-02-03 21:18:19
Encryption key....: 3AD4 1BA6 47B9 1AA3 89CD C29E A6CF 5D5D CADC 0F35
created ....: 2015-02-03 21:18:48
Authentication key: D61E 29B6 9784 15A9 CEFE 08F4 6AD2 1E6C C40C A003
created ....: 2015-02-03 21:19:08
General key info..: pub 2048R/AEB99527 2015-02-03 Elvish Wanderer
<aelana@elfindreams.com>
sec# 4096R/757C0180 created: 2015-02-03 expires: 2015-11-30
ssb> 2048R/AEB99527 created: 2015-02-03 expires: 2015-11-30
card-no: 0006 03362156
ssb> 2048R/CADC0F35 created: 2015-02-03 expires: 2015-11-30
card-no: 0006 03362156
ssb> 2048R/C40CA003 created: 2015-02-03 expires: 2015-11-30
card-no: 0006 03362156
What did you put into the URL field of your card and what is the first
fingerprint:
gpg --card-status | grep ^URL gpg --card-status | grep '^Signature key'
Fixed for 2.1 with 382ba4b.Should be backported to 2.0 and 1.4.
You have the problem only if hidden recipients are used. With 2.1 you
may use this option:
--try-secret-key name
For hidden recipients GPG needs to know the keys to use for trial
decryption. The key set with --default-key is always tried first,
but this is often not sufficient. This option allows to set more
keys to be used for trial decryption. Although any valid user-id
specifica- tion may be used for name it makes sense to use at
least the long keyid to avoid ambiguities. Note that gpg-agent
might pop up a pinentry for a lot keys to do the trial decryption.
If you want to stop all further trial decryption you may use
close-window button instead of the cancel button.This won't be backported to 2.0.
This is not a bug. You need to install a Pinentry and adjust for the changes in
2.1. Please check with ArchLinux or ask at gnupg-users.
But the secret subkeys are not used. Or well, the keyflags should be taken from
the public key. That might not always be the case - in particular not if you
re-create the public key from the secret key.
You can of course repair it using 2.1 because there --export-secret-key takes
the public key and only adds the secret parameters.
What's not clear to me if it is possible to recover a private key that is
damaged this way? If you change expiration with 1.4, the self-signatures are
lost and some key flags are changed. Is it possible to recover from that? That
is the problem I'm concerned with -- if it isn't possible to recover, it seems
people end up with damaged secret subkeys after changing expiration date on a
subkey with gnupg 1.4/2.0.