gpg key with id 85194C08421980C9 not found on keyservers

[dvzrv]

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):

#!/usr/bin/env bash

keyservers=(
    keys.gnupg.net
    keyserver.ubuntu.com
    pgp.key-server.io
    pgp.mit.edu

# curl -sSL https://sks-keyservers.net/status/ | hq 'table.list tr > td:nth-of-type(2)' text | cut -d'[' -f1

cheipublice.ro
key.adeti.org
keys.andreas-puls.de
keys.i2p-projekt.de
keys.jhcloos.com
keys.mental.cash
keys2.kfwebs.net
keyserver-01.2ndquadrant.com
keyserver-02.2ndquadrant.com
keyserver-03.2ndquadrant.com
keyserver.bazon.ru
keyserver.insect.com
keyserver.mattrude.com
keyserver.swabian.net
keyserver.taygeta.com
keyserver1.computer42.org
pgp.cyberbits.eu
pgp.philihp.com
pgp.pm
pgp.skewed.de
pgp.surf.nl
pgp.uni-mainz.de
pgpkeys.co.uk
pgpkeys.eu
pgpkeys.uk
pgpkeys.urown.net
sks.e-utp.net
sks.hnet.se
sks.infcs.de
sks.pod01.fleetstreetops.com
sks.pod02.fleetstreetops.com
sks.srv.dumain.com
a.keys.wolfined.com
a.keyserver.alteholz.eu
a.sks.srv.scientia.net
ams.sks.heypete.com
cheipublice.md
conflux.pgp.intern.ccs-baumann.de
disunitedstates.com
fks.pgpkeys.eu
gpg.phillymesh.net
gpg.planetcyborg.de
healthcheck-lb1.mj2.uk
hockey.ecrypted.ml
ice.mudshark.org
key.bbs4.us
key.blackbearinfosec.com
key.cccmz.de
key.ip6.li
key1.dock23.de
key2.dock23.de
keys-01.licoho.de
keys-02.licoho.de
keys.bonus-communis.eu
keys.communityrack.org
keys.connectical.com
keys.digitalis.org
keys.exosphere.de
keys.fedoraproject.org
keys.fspproductions.biz
keys.indymedia.org
keys.internet-sicherheit.de
keys.jpbe.de
keys.nerds.lu
keys.niif.hu
keys.ppcis.net
keys.riverwillow.net.au
keys.s-l-c.biz
keys.sbell.io
keys.schluesselbruecke.de
keys.sflc.info
keys.stueve.us
keys.techwolf12.nl
keys.thoma.cc
keys.void.gr
keys2.flanga.io
keyserv.sr32.net
keyserver.adamas.ai
keyserver.aktronic.de
keyserver.arihanc.com
keyserver.bau5net.com
keyserver.blazrsoft.com
keyserver.blupill.com
keyserver.bonus-communis-bibliotheca.eu
keyserver.boquet.org
keyserver.borgnet.us
keyserver.br.nucli.net
keyserver.brian.minton.name
keyserver.cdresel.de
keyserver.cns.vt.edu
keyserver.codinginfinity.com
keyserver.compbiol.bio.tu-darmstadt.de
keyserver.dacr.hu
keyserver.dobrev.eu
keyserver.durcheinandertal.ch
keyserver.ecrypted.ml
keyserver.eddiecornejo.com
keyserver.gingerbear.net
keyserver.globale-gruppe.de
keyserver.iseclib.ru
keyserver.ispfontela.es
keyserver.kim-minh.com
keyserver.kjsl.com
keyserver.kjsl.org
keyserver.kolosowscy.pl
keyserver.layer42.net
keyserver.leg.uct.ac.za
keyserver.linuxpro.nl
keyserver.lohn24-datenschutz.de
keyserver.mesh.deuxpi.ca
keyserver.mik-net.de
keyserver.mobexpert.ro
keyserver.mpi-bremen.de
keyserver.nausch.org
keyserver.oeg.com.au
keyserver.opensuse.org
keyserver.paulfurley.com
keyserver.pch.net
keyserver.provonet.nl
keyserver.saol.no-ip.com
keyserver.secretresearchfacility.com
keyserver.securitytext.org
keyserver.serviz.fr
keyserver.siccegge.de
keyserver.sincer.us
keyserver.skoopsmedia.net
keyserver.stack.nl
keyserver.syseleven.de
keyserver.timlukas.de
keyserver.undergrid.net
keyserver.ut.mephi.ru
keyserver.vanbaak.eu
keyserver.vi-di.fr
keyserver.za.nucli.net
keyserver.zap.org.au
keyserver1.canonical.com
keyserver2.canonical.com
klucze.achjoj.info
kr-sks.salac.me
minsky.surfnet.nl
node3.sks.mj2.uk
node4.sks.mj2.uk
openpgp-keyserver.eu
openpgp1.claruscomms.net
pgp.archreactor.org
pgp.benny-baumann.de
pgp.boomer41.net
pgp.cert.am
pgp.ext.selfnet.de
pgp.gwolf.org
pgp.jjim.de
pgp.lehigh.edu
pgp.librelabucm.org
pgp.megagod.net
pgp.net.nz
pgp.ocf.berkeley.edu
pgp.ohai.su
pgp.rouing.me
pgp.unix.lu
pgp.uplinklabs.net
pgp.ustc.edu.cn
pgpkeys.ch
pgpkeys.hu
pgpkeyserver.posteo.de
ranger.ky9k.org
schluesselkasten.wertarbyte.de
sks-cmh.semperen.com
sks-lhr.semperen.com
sks-nrt.semperen.com
sks-peer.spodhuis.org
sks-server.randala.com
sks.alpha-labs.net
sks.b4ckbone.de
sks.bonus-communis.eu
sks.capalino.de
sks.cloud.icij.org
sks.daylightpirates.org
sks.ecks.ca
sks.eq.by
sks.es.net
sks.fidocon.de
sks.funkymonkey.org
sks.heikorichter.name
sks.icij.org
sks.keyservers.net
sks.kserver.eu
sks.mbk-lab.ru
sks.mirror.square-r00t.net
sks.mj2.uk
sks.mrball.net
sks.neel.ch
sks.nimblesec.com
sks.okoyono.de
sks.openpgp-keyserver.de
sks.parafoil.net
sks.pkqs.net
sks.rainydayz.org
sks.rarc.net
sks.research.nxfifteen.me.uk
sks.stsisp.ro
sks.theblains.org
sks.undergrid.net
sks1.home-v.ind.in
sks2.home-v.ind.in
sks2.inx.net.za
skspub.ward.ie
sparkkeys.jhcloos.com
vanunu.calyxinstitute.org
vm-keyserver.spline.inf.fu-berlin.de
whippet.andrewg.com
zimmermann.mayfirst.org
)

for keyserver in "${keyservers[@]}"; do
  gpg --keyserver "$keyserver" --send-key "$1"
done

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?

[dvzrv]

@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]

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 eb411ee) 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) <[email protected]>
[ultimate] (2)  Sebastian Thiel (In Rust I trust) <[email protected]>

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) <[email protected]>
     Sebastian Thiel (In Rust I trust) <[email protected]>

Are you sure that you want to sign this key with your
key "Sebastian Thiel (In Rust I still trust) <[email protected]>" (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]

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]

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]

Works for me.

Hardware failure is a very unfortunate situation. Always make sure, that there are backups!! :)