NO_PUBKEY D85722140244C327 and no way to verify it #486

On Ubuntu, attempt to upgrade palemoon produces error message

W: GPG error: http://download.opensuse.org Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D85722140244C327

The instructions on https://software.opensuse.org/download.html?project=home%3Astevenpusser&package=palemoon recommends downloading key from INSECURE (http) url and adding it.

That's similar level of security as posting your root password on facebook.

You should put your public key on some location it can be obtained from SECURELY and change the links on that page. Alternatively, put the key directly INTO that page.

On Ubuntu, attempt to upgrade palemoon produces error message W: GPG error: http://download.opensuse.org Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY D85722140244C327 The instructions on https://software.opensuse.org/download.html?project=home%3Astevenpusser&package=palemoon recommends downloading key from INSECURE (http) url and adding it. That's similar level of security as posting your root password on facebook. You should put your public key on some location it can be obtained from SECURELY and change the links on that page. Alternatively, put the key directly INTO that page.

I've sent Steve a message asking him about this.

FTR: Public keys are public. Please read up on how PKI works before making assumptions about security levels of public keys posted.

Steve should probably just upload his public key to a key server. If desired, he should ask for counter signatures to his key pair.

FTR: Public keys are public. Please read up on how PKI works before making assumptions about security levels of public keys posted. Steve should probably just upload his public key to a key server. If desired, he should ask for counter signatures to his key pair.

wolfbeast: Of course public keys are public. I meant that person who will download public key from insecure URL and add it is doing something similarly safe as posting root password on facebook (or github - not sure about facebook, but people actually posted various keys and passwords on github). There is no way to verify that the public key they downloaded is actually from Steve - it could've been changed in transit.

Yes ... uploading the key to key server should also work.

wolfbeast: Of course public keys are public. I meant that person who will download public key from insecure URL and add it is doing something similarly safe as posting root password on facebook (or github - not sure about facebook, but people actually posted various keys and passwords on github). There is no way to verify that the public key they downloaded is actually from Steve - it could've been changed in transit. Yes ... uploading the key to key server should also work.

@hkmaly a root password is private, not public - please don't compare the two because that's all backwards 😄 -- of course posting a private key or phrase anywhere public is a bad idea. Not so for public keys though. There is also no reason for anyone to alter public keys in transit because it will change the cryptographic ID/fingerprint of the key to begin with and the resulting key won't be having any trust level.
Also, downloading someone's public key, valid or not, won't be compromising the downloader's security in any way -- once again, please take some time to understand how asymmetrical cryptographic signing through PKI works.

Ultimately it boils down to this: Trust that the key actually belongs to Steve can only be asserted by having other people sign that key with their cryptographic signature after verifying it belongs to Steve; that is the way PKI trust works. This is why I said to ask for counter signatures on his key pair to establish trust of identity.

@hkmaly a root password is private, not public - please don't compare the two because that's all backwards :smile: -- of course posting a private key or phrase anywhere public is a bad idea. Not so for public keys though. There is also no reason for anyone to alter public keys in transit because it will change the cryptographic ID/fingerprint of the key to begin with _and_ the resulting key won't be having any trust level. Also, downloading someone's public key, valid or not, won't be compromising the downloader's security in any way -- once again, please take some time to understand how asymmetrical cryptographic signing through PKI works. **Ultimately it boils down to this:** Trust that the key actually belongs to Steve can only be asserted by having other people sign that key with their cryptographic signature after verifying it belongs to Steve; that is the way PKI trust works. This is why I said to ask for counter signatures on his key pair to establish trust of identity.

I've uploaded the public key to the public key server pool. It should propagate to other public servers shortly.

@wolfbeast You might want to take some time to understand how cryptographic signing of packages work. Short version: Installation of package is done with root privileges. By installing unknown package, you are giving author of that package root access to your machine. That's why all distributions nowadays sign the packages, so noone (except the authors of distributions) can put some malware in them. But if the package is signed by unknown key, it won't be more secure - someone can switch that package IN TRANSIT or in repository. If it's signed by key which is SUPPOSED to belong to Steve, but the key itself is not downloaded in secure way, both package and key can be replaced.

While having the key signed by someone's else key is preferred method and the way PKI trust works, there are other ways how to raise trust in the key - of course, cryptographically. For example, if the key is on HTTPS server, it's equivalent to the server key signing the fact the key is really being downloaded from that server and wasn't replaced in transit. Which, while not nearly as good as having the key signed by someONE's else key, is considerably better than not having signed it at all.

(Hmmmm ... true, replaced key wouldn't have the fingerprint D85722140244C327 ... but, so far noone confirmed that fingerprint is correct. Only thing the instruction page says is: get the key which is in the file next to the package so anyone getting on that server OR anyone who can alter your traffic to that server can replace both at once easily. That's as if the file wouldn't be signed at all.)

PS: Yes, I realize that I didn't explain myself clearly on first try. I assure you my knowledge about asymmetric cryptography is better than how it looks from the first post.

@wolfbeast You might want to take some time to understand how cryptographic signing of packages work. Short version: Installation of package is done with root privileges. By installing unknown package, you are giving author of that package root access to your machine. That's why all distributions nowadays sign the packages, so noone (except the authors of distributions) can put some malware in them. But if the package is signed by unknown key, it won't be more secure - someone can switch that package IN TRANSIT or in repository. If it's signed by key which is SUPPOSED to belong to Steve, but the key itself is not downloaded in secure way, both package and key can be replaced. While having the key signed by someone's else key is preferred method and the way PKI trust works, there are other ways how to raise trust in the key - of course, cryptographically. For example, if the key is on HTTPS server, it's equivalent to the server key signing the fact the key is really being downloaded from that server and wasn't replaced in transit. Which, while not nearly as good as having the key signed by someONE's else key, is considerably better than not having signed it at all. (Hmmmm ... true, replaced key wouldn't have the fingerprint D85722140244C327 ... but, so far noone confirmed that fingerprint is correct. Only thing the instruction page says is: get the key which is in the file next to the package so anyone getting on that server OR anyone who can alter your traffic to that server can replace both at once easily. That's as if the file wouldn't be signed at all.) PS: Yes, I realize that I didn't explain myself clearly on first try. I assure you my knowledge about asymmetric cryptography is better than how it looks from the first post.

I'm well-aware of how cryptographic signing of packages works.

If the package and key are replaced in the repo/on the server, meaning a compromised server account of Steve, then https won't help you. This would also be immediately noticeable to anyone observing the repo/server.

In-transit replacement of both package and key is a lot more involved than you might think, and indeed the ID would be different. Once I get a hold of Steve I'm sure I'm able to verify ownership and sign his key.

I'm well-aware of how cryptographic signing of packages works. If the package and key are replaced in the repo/on the server, meaning a compromised server account of Steve, then https won't help you. This would also be immediately noticeable to anyone observing the repo/server. In-transit replacement of both package and key is a lot more involved than you might think, and indeed the ID would be different. Once I get a hold of Steve I'm sure I'm able to verify ownership and sign his key.

I've not received any response from Steve. You'll just have to verify the key yourself with him, and if done, sign and send to server to help the trust model of that key.
Closing.

I've not received any response from Steve. You'll just have to verify the key yourself with him, and if done, sign and send to server to help the trust model of that key. Closing.

FTR: I got a response and apparently this key is generated by the distribution platform. Its trust will go as far as the trust in the package generator. I'm not inclined to sign these kinds of keys and I don't recommend anyone else does this either because the private keys will not be in the hands of the package authors.

Sooo ... did you (or Steve) though about switching to more secure distribution platform?

This really looks as "the package is signed with key which is as trustworthy as if it wouldn't be signed at all" situation.

Sooo ... did you (or Steve) though about switching to more secure distribution platform? This really looks as "the package is signed with key which is as trustworthy as if it wouldn't be signed at all" situation.

Take it up with Steve. He's the one responsible for the contributed build.

Labels Milestones

NO_PUBKEY D85722140244C327 and no way to verify it #486