1.4 has been released - waiting for 2.0
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Aug 18 2016
Aug 5 2016
Jul 15 2016
Jul 6 2016
Fixed in the repo STABLE-BRANCH-1-4.
Forward ported to STABLE-BRANCH-2-0.
It's not in master (2.1).
Mar 19 2016
I took a look at the source code and now understand what is going on here.
The code indicates: One or more secret keys (primary or sub) were found.
But the UI message suggests that the secret key of the current (primary) key was
found, hence my confusion.
Here are some ideas:
- EASY: Update the message to indicate it is generic and not specific to the key
being edited.
OR
- HARDER: Improve the logic so the message is specific to the key being edited.
Thoughts?
Mar 18 2016
Here you go:
My master key is offline and I have subkeys on a Yubikey. As expected, I see sec# when listing keys when using the
online system:
gpg -K
sec# 4096R/2FFA7695 2016-02-01 [expires: 2020-01-31]
uid NAME <EMAIL@ADDRESS.COM>
ssb> 2048R/EA7CCF1B 2016-02-01
ssb> 2048R/1E8DA9B9 2016-02-01
ssb> 2048R/5BA60C24 2016-02-01
However, when I go into edit mode, gpg indicates that the "Secret is available":
gpg --edit-key 2FFA7695
gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 4096R/2FFA7695 created: 2016-02-01 expires: 2020-01-31 usage: C
trust: ultimate validity: ultimate
sub 2048R/EA7CCF1B created: 2016-02-01 expires: 2018-01-31 usage: S
sub 2048R/1E8DA9B9 created: 2016-02-01 expires: 2018-01-31 usage: E
sub 2048R/5BA60C24 created: 2016-02-01 expires: 2018-01-31 usage: A
[ultimate] (1). NAME <EMAIL@ADDRESS.COM>
[ultimate] (2) [jpeg image of size 1234]
Tested with several recent versions of GnuPG. Am I misunderstanding this message?
Please describe the error _here_ and do not link to an external page.
Mar 17 2016
and there is no w64 version of 1.4
We won't fix such things for 1.4 (Windows)
Mar 16 2016
Bug system broke the link URL. Here is a shorter one:
http://security.stackexchange.com/q/115230/16036
Feb 1 2016
Jan 21 2016
This is caused by gpg inability of merging the secret keys. We can't fix that
in 1.4 or 2.0. 2.1 does not have this problem anymore.
Jan 7 2016
Sorry, I can't see any problem here.
The "priotr-old" key is actually the newer key because an expiration date was
added to that copy of the key (2012-07-09) and that key has meanwhile expired.
Thus you can't encrypt using this key.
When you import the "piotr" key that is actually the same key but w/o the update
with the expiration date. Thus gpg does not chnage the exiting in key because
the existing key has a newer self-signature (where the expiration date is
stored) than the new key. So nothing changes, which is correct.
If you delete the .gnupg directory you don't have the newer key and by importing
the key w/o the expiration date you can encrypt to that key.
Jan 6 2016
Same behaviour with gpg-2.1.10 (Arch), libgcrypt 1.6.4.
Jan 5 2016
1.4.12 is heavily outdated (from 2012). Please update to 1.4.20 or at least
1.4.19 and check again.
Commit e70f7a5 fixes this for 2.1.
Should be backported.
Thanks.
Dec 31 2015
Dec 27 2015
As I am not sure how to attach files to this report I have uploaded them here:
http://www.elstel.org/uploads/gnupg/
Dec 17 2015
backported by dkg with commit 0c3d764 for 1.4.19
Dec 11 2015
Thanks for helping keep track of all these issues.
Yes this only fixes the problem that has already been fixed in the last Gpg4win
Versions. So that this will be fixed in future gnupg-2.1 versions.
Still to help us better seperate the problems I would like to close this as for
me this bug was about "Wrong encoding in a localized version".
- the more critical "passphrase with non ASCII characters" problem (as reported
only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?
I actually overlooked this in this issue. Can you please open another issue for
that. And add me to the Nosy.
- the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-
strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)
If this problem was still existing with gpg4win this is still a problem.
- the "charset weirdness searching keyserver for some non-ASCII user IDs under
non-UTF-8 locales" (as reported in Issue 1514).
This appears not to be windows specific. Also I think this works except for
cases where the Key in question is problematic. If I search on windows for
emanuel@intevation.de I get the correct Umlauts shown. Might be a Problem though
for characters that are unrepresentable in the 8 Bit codepage.
It sounds great!
So this patch, as the previous one, solves the "incorrect display of GPG 2
output translated into another language" (as reported here and previously also
in Issue 1373 and Issue 1674).
Does this patch solve also the "incorrect display of filenames with non ASCII
characters" (as reported here and previously also in Issue 1409)?
By the way, as I understand, this patch doesn't fix:
- the more critical "passphrase with non ASCII characters" problem (as reported
only here, see T1691 (andreaerdna on Aug 19 2014, 02:36 AM / Roundup)); does this bug need a
dedicated new Issue to be addressed and solved?
- the "utf-8 encoding of encrypted filenames" / "strange behaviour of --utf8-
strings, --no-utf8-strings and --charset options" (as reported in Issue 1409 ad
probably similar to Gpgtar Issue 1624 / Gpa Issue 2185)
- the "charset weirdness searching keyserver for some non-ASCII user IDs under
non-UTF-8 locales" (as reported in Issue 1514).
After some more discussion and testing in the development jabber channel werner
agreed to include this patch. Pushed to libgpg-error with 823e858. So this will
hopefully be part of the first gnupg modern release that will include localization.
Updated Patch against libgpg-error where this code now lives.
Please apply this patch or something similiar.
The problem I can see is that with this code in libgpg-error now GUI
applications may use it which want to get "GUI Native".
Probably better to introduce a new function "wchar_to_console" ? And use it from
GnuPG. Does GPA use that conversion function?
Might be a good time for this now where gnupg master already depends on new
symbols in libgpg-error.
Dec 9 2015
Some more infos:
https://www.openkeychain.org/faq/#importing-your-own-key-from-gnupg-fails
says that this is a problem for a number of people.
Werner told me that porting the fix back would mean to basically
migrate 2.0 to 2.1, which is useless because 2.1 is already 2.1.
Another possibility would be to change --export to mix public keys (certs)
with secret keys. This would create other problems and thus is not
adviable for a stable version.
So I think this is "won't fix" because it (technically) does not make
sense to fix in 1.4 or 2.0. Solutions: Use 2.1 or wait for 2.2.
As importing implementation: Be tolerant for this problem man use the cert
information if you can.
Nov 25 2015
Nov 20 2015
As Werner stated, this appears to be a user support inquiry, which is better
answered elsewhere. As such, I'm marking this issue as resolved.
dkg: I've now applied your backport to the 1.4 branch. Sorry for not doing this
sooner. I believe that this now completely rectifies this issue. As such, I'm
marking this issue as resolve. Thanks.
Nov 19 2015
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.
Nov 18 2015
Based on Werner's comment, this issue has been addressed. As such, I'm closing
this bug report.
Nov 6 2015
Nov 2 2015
Sep 9 2015
Sorry, I missed that for 2.0.29
Sep 8 2015
2.0.29-beta has a fix for this. See also T1823.
Sep 4 2015
Sep 1 2015
Aug 27 2015
Jul 22 2015
If you can't do that we can't help you here. You should contact a commercial
supporter (cf. https://gnupg.org/service.html).
Please note that 1.4.12 has security problems and should be updated anyway.
Jul 21 2015
I can't do it on production environment.
Have to fix it like it is, but still don't know where is an issue.
Jul 1 2015
Jun 30 2015
May 11 2015
This looks more like a problem with the way that versionnhas been build in
Fedora. I suggest to take this problem to Fedora or the gnupg-users mailing list.
Feb 18 2015
Feb 4 2015
Jan 27 2015
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.
Jan 5 2015
Sep 17 2014
No, he can't. The data received from a keyserver is by defintion unreliable.
It may be any kind of trash. gpg takes care of ensuring that the data (i.e. the
keys) are consistent.
There has been a long and heated debate over this recently on whether the
additional check introduced with 1.4.18 is at all useful. In any case what you
requested is in all recent versions of gpg. I thus close this bug.