Would be nice if launchpad understood their bug tracker so it would
link. Whenever they do fix it we may want to cherry pick it so this
doesn't bite other people upgrading to 18.04.
** Changed in: gnupg2 (Ubuntu)
Status: New => Triaged
** Changed in: gnupg2 (Ubuntu)
Importance:
Oh wow. fail. I'm not sure it's worth tracking here, given it is an
upstream issue. I guess we can set this bug to trianged.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/110
Title:
gpg throws
Yea, the tripping point for me was that I was importing a single file
with both private and public keys in it, and that wasn't fixing it. The
import has to be of *only* the public keys. Hopefully upstream will fix
that part so the upgrade ( which automatically does an export/import )
will then
So yeah, my suggestion to reimport public key was right. It is an odd
corner case. I think it has to do with something how the upstream choose
to reorganize public & secret keyrings; such that the split of which
bits need to be where is now different, and the export of old is either
incomplete for
Here is the upstream bug report, which launchpad apparently does not
recognize:
https://dev.gnupg.org/T3101
The workaround is to re-import only the public key, or in my case, I
just did a --recv-keys to fetch it from keyserver.ubuntu.com and that
pulled in the updated selfsig.
I understand that
Is the public key, with the new expiry date, and that selfsig, imported?
Sounds like an upstream bug.
Can we replicate that bug now with fresh keys? e.g. make key past-expiry
(possibly under faketime), make subkey, extend master key expiry, export
subkeys, import subkeys, see them expired? or
Ahah, gpg -K -v shows them... it seems to think they are all expired.
It lists the expiration date on my current key as 2018-1-6. I believe
that was the *original* expiration date, but then I extended it. gpg
2.1 seems to be failing to recognize the extension.
--
You received this bug
So I went back to 2.0.31, deleted ~/.gnupg, imported my keys, made sure
they all showed up, then upgraded to 2.1.1. It converted to the new
keybox format, and... my private keys are all gone.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
So I cloned the upstream git repo and built 2.0.31 and it works. 2.2.4
does not. Anywhere in the 2.1 area in between seems to have some
protection turned out to tell you not to use production keys with a
development branch and it refuses to import *any* secret key. Any idea
how to bypass this?
I noticed something different about the new version of gpg is that I get
a full screen prompt for my password when importing, but the old version
does not do that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Generating a new keypair and exporting only the subkey and then
importing it into 18.04 seems to work. There must be something
particular about my existing keychain. I guess I'll have to start git
bisecting.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
can you provide commands to generate test keys/subkeys, to recreate
this?
i do not appear to loose any subkeys at all, and i use subkeys only by
default, without master key.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
The permissions are probably world readable because as I said, I tried
deleting the whole directory and recreating it by hand, then copying the
secring over from the working system. This was after deleting the whole
directory and letting gpg recreate it, then importing the keys exported
from a
what are the permissions of /home/psusi ? and /home/psusi/.gnupg ?
it is not safe if .gnupg; or the directory that contains it; are
group|other writable.
new gpg uses keybox, whilst old gpg uses pub/secring.gpg. whenever new
gpg was first executed against this .gnupg the old secring got auto
14 matches
Mail list logo
