Closed dvzrv closed 3 years ago
dvzrv
commented
4 years ago @Byron Meanwhile the key in question has appeared on the SKS infrastructure.
Unfortunately the README still states your previous key as the one to verify against.
I will not be able to update to 3.1.8 (or beyond) until a chain of trust between the old and the new key is established. Please sign your new key with your old key and publish this to the key servers as well. Also, please adjust the README accordingly. Thanks!
Byron
commented
4 years ago Thanks for your help on this. Indeed I did my best to manually bring the new key into a few keyservers, and apparently it worked.
Just now I have updated the README to match the new key, everything seems to pan out.
Since I am unable (see eb411ee92d30675a8d3d110f579692ea02949ccd) to establish a chain of trust I guess that is it with Arch linux releases. It's sad to see them go because of that. After all, this should not have happened and I am refraining from blaming myself too much for it. GPG is just a great mess and I don't trust it a bit specially when smartcards/yubikeys are involved. I think it really just lost the connection to the smartcard, so doesn't know where to look for the key. I have no idea how to restore this except for looking in backups, and tbh I would rather let that particular key die (it's USB-A) than spending more time on it.
Update: Apparently there is no connection to the card because gpg claims to have the private key, but when trying to use it, it seems to have no signing key.
gpg --sign-with 290C92C81ED4BA3ABB343722296B26A2B943AFFA --sign-key 27C50E7F590947D7273A741E85194C08421980C9
sec rsa4096/85194C08421980C9
created: 2020-07-17 expires: never usage: SC
card-no: 0006 07676842
trust: ultimate validity: ultimate
ssb rsa4096/AA962CF063C2F55A
created: 2020-07-17 expires: never usage: E
card-no: 0006 07676842
ssb rsa2048/0C63F0D9347C9843
created: 2020-07-17 expires: never usage: A
card-no: 0006 07676842
[ultimate] (1). Sebastian Thiel (YubiKey USB-C) <byronimo@gmail.com>
[ultimate] (2) Sebastian Thiel (In Rust I trust) <sebastian.thiel@icloud.com>
Really sign all user IDs? (y/N) y
sec rsa4096/85194C08421980C9
created: 2020-07-17 expires: never usage: SC
card-no: 0006 07676842
trust: ultimate validity: ultimate
Primary key fingerprint: 27C5 0E7F 5909 47D7 273A 741E 8519 4C08 4219 80C9
Sebastian Thiel (YubiKey USB-C) <byronimo@gmail.com>
Sebastian Thiel (In Rust I trust) <sebastian.thiel@icloud.com>
Are you sure that you want to sign this key with your
key "Sebastian Thiel (In Rust I still trust) <sthiel@thoughtworks.com>" (296B26A2B943AFFA)
Really sign? (y/N) y
gpg: signing failed: No secret key
gpg: signing failed: No secret key
Key not changed so no update needed.The best chain of trust I can establish is through keybase. Depending on your threat model, this may or may not be enough.
In any case, thanks for all the effort that you have inevitably put into maintaining the Arch linux packages, and it would be sad to see them go.
dvzrv
commented
4 years ago In any case, thanks for all the effort that you have inevitably put into maintaining the Arch linux packages, and it would be sad to see them go.
Hm, maybe you misunderstood me there. I did not say that I will not maintain this package any further. Only that I can't upgrade it willy-nilly if a chain of trust can not be established! :)
Hm, it's unfortunate that you have issues with your yubikey. Do you have an update of either key in a safe location? Maybe you can use that instead? If you intend not to use the previous key afterwards anyways, you can additionally revoke it after signing the new key (that's the most clear - for outsiders - thing to do I guess).
Byron
commented
4 years ago Unfortunately that 'old' yubikey had an on-device key only, no backups exist nor is there a revocation key. For the current one I didn't make the same mistakes at least.
However, looking at how keybase works, I believe it serves as prove of ownership of the private key portion of the keys listed there, here is the docs of the respective command.
AME:
keybase pgp select - Select a key from GnuPG as your own and register the public half with Keybase
USAGE:
keybase pgp select [command options] [key query]
DESCRIPTION:
"keybase pgp select" looks at the local GnuPG keychain for all
available secret keys. It then makes those keys available for use with keybase.
The steps involved are: (1a) sign a signature chain link with the selected PGP
key and the existing device key; (1b) push this signature and the public PGP
key to the server; and if "--import" flag is passed: (2a) copy the PGP secret half
into your local Keybase keyring; and (2b) encrypt this secret key with Keybase's
local key security mechanism.
By default, Keybase suggests only one PGP public key, but if you want to,
you can supply the "--multi" flag to override this restriction. If you
want your secret key imported into the local Keybase keyring, then use
the "--import" flag. Importing your secret key to Keybase keyring makes
it possible to use Keybase PGP commands like "pgp decrypt" or "pgp sign".
If you don't want to publish signature chain link to Keybase servers, use
"--no-publish" flag. It's only valid when both "--no-publish" and "--import"
flags are used.
This operation will never push your secret key, encrypted or otherwise,
to the Keybase server.
OPTIONS:
--multi Allow multiple PGP keys.
--import Import private key to the local Keybase keyring.
--no-publish Only import to Keybase keyring, do not publish on user profile.Since I was able to add the 'AFFA' key later, I must have had the private portion of it. Even though this won't prove that one entity had access to both keys at the same time (which is impossible now), it's great prove that 'someone with access to the byronbates' account on keybase had access to these keys at some point in time.
As Keybase also has proof that this github account is under control of the user who own the keybase account, I think it should be reasonable to assume that this is indeed the person I claim to be. Maybe this boils down to how much one trusts keybase.
Whats your take on it?
dvzrv
commented
3 years ago Works for me.
Hardware failure is a very unfortunate situation. Always make sure, that there are backups!! :)
Hi! When trying to package 3.1.8 for Arch Linux I was unable to retrieve your public key from the keyservers. Can you upload it? If it has already been uploaded to one of the SKS servers, consider using something like the following to force-push the key to every keyserver (note: will take some time and some of the keyservers are probably not around anymore):
The SKS stuff is pretty broken and syncing may take days or never happen.
Apart from that: Is there any commit or document that documents the change in signing key to establish a chain of trust?