5

I asked a recent, separate Ask Ubuntu question with the following in the body:

W: An error occurred during the signature verification. 
The repository is not updated and the previous index files will be used. 
GPG error: https://dl.winehq.org/wine-builds/ubuntu bionic InRelease: 
The following signatures couldn't be verified
 because the public key is not available: NO_PUBKEY 76F1A20FF987672F

As you can see part of my error message exposes PUBKEY 76F1A20FF987672F. Was this the public key of WINE, or is this my own public key?

Most importantly, is this PUBKEY 76F1A20FF987672F information I should NOT be posting on a public forum (this one)?

I assume a private key is the only thing I would never want to divulge. I'm reading Wikipedia's Public-key cryptography page now, but it's a little overwhelming.

  • 4
    Most apps wouldn't (i.e., shouldn't) show a secret key in this form in a warning or error message, and it would be a mistake to do so. It is safe to divulge this public key. – user459652 Dec 20 '18 at 15:48
  • 1
    @jason-hunter That's Wine's public key and no one shares their private key, they only shares public key. – Pavel Sayekat Dec 20 '18 at 15:50
  • 1
    How does asymmetric encryption work? – RoVo Dec 20 '18 at 15:51
  • 1
    Although it turns out to be safe to post, it is probably worth pointing out that if you had any concerns that it might have been a private key, you probably shouldn't have posted the real value, just in case it was private. – TripeHound Dec 20 '18 at 21:09
  • Sometimes I play dumb in my questions, as a courtesy to others who may not know such things (likely story, eh) and to obtain a more complete answer. But, yes your sentiment is absolutely correct. I wouldn't do, or advocate, posting publicly what ought not be posted publicly. – Jason Hunter Dec 20 '18 at 21:48
11
76F1A20FF987672F

No! This is the keyID of the key-pair from Winehq.org!!

This is not your public (or private) key. You probably don't have one yet. If you ever need a private-public key pair, you will have to create them.

The keyID is like the number on a physical key. the same number is also on a lock the key belongs to. There is no harm in posting this information in a public forum. The private key of winehq is safely with the... (guess who?)

WineHQ

WineHQ changed their private-public key combination. Why? The same reason people change their locks. Physical keys (and digital keys) get lost (or deleted) or stolen.

See signature verification error for wine - index files failed to download - changing mirror doesn't help for how to download the new public key from WineHQ. Once you have the new public key, the update will go through. The new public key will verify that the wine update is coming from the WineHQ and noone else. That is because only WineHQ has the matching private key.

Hope this helps

  • Comment: The downside of regularly changing the keys is that your security level effectively goes down to the protection level for the communications channel(s) you use to communicate the new public key to your customers (or those channels you don't currently use, but through which customers would believe an imposter executing an attack with social engineering). – WBT Dec 21 '18 at 17:26
4

76F1A20FF987672F is an identifying code number for both the public and private key that is associated with the releases stored in this APT repository. It is not a complete key - neither public nor private - and it is useless by itself.

The normal thing to do with one of these code numbers is feed it to gpg --recv-keys to load the complete public key into your local key ring, but this particular public key isn't on the usual "key servers". There are instructions on https://wiki.winehq.org/Ubuntu for how to get it:

wget -nc https://dl.winehq.org/wine-builds/winehq.key
sudo apt-key add winehq.key

Running both of those commands should make apt-get update happy again.

Running just the first command will give you a file containing the complete public key corresponding to the identifying code number. You can learn something about its contents with this command:

$ gpg --list-packets < winehq.key | less

The interesting part of the output is right at the beginning:

# off=0 ctb=99 tag=6 hlen=3 plen=397
:public key packet:
    version 4, algo 1, created 1544460984, expires 0
    pkey[0]: [3072 bits]
    pkey[1]: [17 bits]
    keyid: 76F1A20FF987672F
# off=400 ctb=b4 tag=13 hlen=2 plen=39
:user ID packet: "WineHQ packages <wine-devel@winehq.org>"

The "keyid" is the same identifying code number, and the "user ID" is an email address associated with WineHQ. However, don't take that for granted -- whoever generated this key could have set the "user ID" to anything at all. The normal way to determine whether a PGP key belongs to the person or organization you think it does is with the "web of trust", but this key isn't in the web of trust at all, so we have to rely on the fact that we got it from an HTTPS website belonging to the Wine project. This is probably good enough.

"created 1544460984" tells you when the key was created, but in an unhelpful way: that number is a count of seconds since the Unix epoch. You can turn it into something human-readable with the date command:

$ date --date='@1544460984'
Mon Dec 10 11:56:24 EST 2018

It was created just ten days ago (as of when I'm writing this). This is probably why you were getting errors from APT -- they changed their key quite recently. This is a suspicious thing to have happen, but there's a note on https://wiki.winehq.org/Ubuntu saying that they did change their key, so it's probably legit, unless the entire winehq.org site has been compromised.

The raw contents of winehq.key look like this:

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGNBFwOmrgBDAC9FZW3dFpew1hwDaqRfdQQ1ABcmOYu1NKZHwYjd+bGvcR2LRGe
R5dfRqG1Uc/5r6CPCMvnWxFprymkqKEADn8eFn+aCnPx03HrhA+lNEbciPfTHylt
[48 more lines of base64]
-----END PGP PUBLIC KEY BLOCK-----

You can see that this is much larger than the code number. For comparison, a PGP secret key looks something like this. It's even bigger.

-----BEGIN PGP PRIVATE KEY BLOCK-----

lQVYBFwb3HkBDACz89KGuIp/A7whjsCVH8qZM/HL5iTesD/4pncO770Z7y15sIJx
gN+JU/SShGUPPF5oWJqJyYIINkrlgBNYtYg1tfGN0hjE+IVefrrOgYGCdyiEJEKc
[76 more lines of base64]
-----END PGP PRIVATE KEY BLOCK-----

(That's a key I created just for the sake of writing this answer, never used to sign or encrypt anything, and immediately destroyed, even though you probably can't do anything interesting if you only have the first 96 bits of a PGP secret key.)

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.