Can't verify command line tools binary using gpg

kmundnic

I'm trying to set up the command line tools following the instruction on this site: https://support.1password.com/command-line-getting-started/ I downloaded the CLI tool from this website: https://app-updates.agilebits.com/product_history/CLI, and I'm trying to verify the op binary, but I get the following message:

I downloaded CLI tool v0.3.

$ gpg --verify op.sig op
gpg: Signature made Tue Feb 13 14:38:02 2018 PST
gpg: using RSA key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22
gpg: Good signature from "Code signing for 1Password <1password's email>" [unknown] # Removed the email in this line before posting
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.

The RSA key is the same that the one on the first link I included in this message. Any information on why it's not being verified would be appreciated.

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: macOS 10.12.6
Sync Type: Not Provided

Ben

Hi @kmundnic

What you've posted is the expected output. The important bit is:

gpg: Good signature from "Code signing for 1Password <codesign@1password.com>" [unknown]

Thanks :)

Ben

kmundnic

Thanks Ben

Ben

You're welcome. :)

Ben

jpgoldberg

As @ben said, this is expected behavior. The signature check did prove that what op was signed by the PGP key with the fingerprint 3FEF9748469ADBE15DA7CA80AC2D62742012EA22.

For those curious about the warning, there is a lesson that requires a history lesson. And it is the lesson of why PGP did not come to rule the world and bring "pretty good privacy" to the masses. There is no reason for anyone to read what I've written below. It has turned into a bit of a rant about the problems of PKI.

A tangled web of trust

The specific warning is that although the signature check proves that the file was signed by key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22 it does not tell you that that key actually belongs to us. Over the decades there have been four general approaches to Public Key Infrastructure (PKI) for addressing this kind of problem.

1. Hierarchical trust. This includes X509 and what is used for things like SSL/TLS.
2. Web of Trust. This is what PGP is supposed to rely on.
3. Pairwise key verification. A well thought out example of this is what Signal does. But this doesn't scale for things like the web or code signing keys.
4. Ignoring the problem entirely. This is what most people faced with 2 and 3 actually do. It's hard enough to get people to pay attention to browser warning on number 1. Do pay attention to browser certificate warnings.

So (correctly) telling you not to worry about that warning is an instance of (4). That is because making effective use of (2) doesn't work. Even people who understand how it is supposed to work, don't do what is required to make it work because it just puts too many burdens of the user. By the way, I should mention that back in the 90s I was a huge advocate of PGP and attempted to train people to use it.

One of the major problems with the Web of Trust is that it only works if a sufficient portion of users understand the distinction between trusting the identify of a key and trusting the key owner as an introducer. So Patty (a very clever dog) must distinguish between trusting that a particular key belongs to Molly (a not so clever dog) and trusting Molly's judgement and practices when Molly signs other keys.

Patty may have good reason to believe that a particular key she has belongs to Molly. But when Molly uses her key to say that some particular key belongs to Jack (the chihuahua down the road), Patty needs to consider how carefully Molly checked. Perhaps the key that Molly thinks is Jack's actually belongs to Mr Talk (neighbor's cat) masquerading as Jack.

This is subtle distinction. It's not particularly difficult for people to understand if they are taught, practice it, and are motivated to take the time and effort to understand it. But that is just not a reasonable thing to expect of most people, who would have to make these choices about every key they sign.

You can see which keys have signed our PGP code signing key:

$ gpg --check-sigs 3FEF9748469ADBE15DA7CA80AC2D62742012EA22
pub   rsa4096 2017-05-18 [SC] [expires: 2025-05-16]
      3FEF9748469ADBE15DA7CA80AC2D62742012EA22
uid           [  full  ] Code signing for 1Password <codesign@1password.com>
sig!3        6C5106670990BD6E 2017-05-19  Jeffrey P. Goldberg <jeffrey@goldmark.org>
sig!         F7877A2BC9C40C31 2017-09-06  Justin R. Miller [email redacted]
sig!         BD58E71C42F3D4D4 2017-05-19  AgileBits Support (Agile Web Solutions became AgileBits) <support@agilebits.com>
sig!3        11542BC0DE879F23 2017-05-19  Jeffrey Goldberg <jeff@agilebits.com>
sig!3        33375D0CABA65660 2017-05-25  Jeffrey Alles (Keybase GPG Key Pair) [email redacted]
sig!3        4DA180538EB83770 2017-05-24  Jeffrey Alles [email redacted]
sig!3        E546819A5A8918A9 2017-09-16  Roustem Karimov [email redacted]
sig!3        E25C1E01F3A98447 2017-09-16  Roustem Karimov [email redacted]
sig!         2DFB7ED0057A3EA3 2017-05-19  keybase.io/stimur <stimur@keybase.io>
sig!3        AC2D62742012EA22 2017-05-18  Code signing for 1Password <codesign@1password.com>

(It's sort of silly to redact the email addresses, as you can all see them by issuing the above command.)

So those are people who have all said that they have checked that the key 3FEF9748469ADBE15DA7CA80AC2D62742012EA22 really belongs to "Code signing for 1Password codesign@1password.com".

Now you may well trust me to only sign keys that I have good reason to believe belong to their purported owner. So if you trust that either of the two keys listed genuinely belong to me, then you can trust that the codesigning key really belongs to us. Perhaps my key has been signed using a key that you both trust the identify of and trust that the person would only sign keys appropriately. Or perhaps you have verified one on my keys independently (I may have personally handed to you my business card).

Or perhaps you only trust that Roustem and I are both who we say we are, but you only half way trust us to sign keys carefully, two "half-way" trusting for that purpose is good enough. Or perhaps ...

Perhaps a system that depends on people understanding all of that isn't going to work well.

So you can go and read all of the PGP/GnuPG documents and advice on trusting keys and take steps to see that you trust that our key really does belong to us. Or you can just do number (4). Unless you are particularly curious and have some time on your hands, I recommend (4). And because we have published that key fingerprint here and on our support website, we then you can use the trust you have in TLS for either of these sites as reason to trust that that is the right key.

PKI is hard. The most "secure" systems place a substantial burden on the user and so end up lacking real security because users don't do what the system requires. So we are largely struck with (1) with all its problems.

c__

Hi @jpgoldberg ,

Do you serve the AgileBits full GPG public key over HTTPS anywhere? I see the fingerprint, but am having trouble locating the full key contents. Given we trust the fingerprint wasn't tampered with via HTTPS CA PKI, I don't see why we can't trust the CA PKI to just deliver the key contents directly. (If someone could tamper with the key over SSL, they could also tamper with the fingerprint.)

(I don't use GPG outside of verifying your signed CLI binary, and don't have any GPG keyservers configured. So the documented --receive-keys fails with keyserver receive failed: No route to host.)

Edit: for others with the same problem, I was able to locate the key contents using this keyserver website. You will need to confirm the fingerprint matches after importing, because Agilebits does not control pgp.mit.edu's SSL certificate. That can be done with gpg --list-public-keys.

Thanks,
C

jpgoldberg

Do you serve the AgileBits full GPG public key over HTTPS anywhere?

That is a good question. I don't have an answer for you, but I will raise the issue with our documentation and website teams to have a place where we can publish all of our public keys.

Given we trust the fingerprint wasn't tampered with via HTTPS CA PKI, I don't see why we can't trust the CA PKI to just deliver the key contents directly.

Yep.

A lot of the habits that people have today regarding posting fingerprints and hashes date back from the days when TLS was expensive. So you'd post a hash on an HTTPS site, while what it is a hash of would be transmitted over a cheaper and less secure channel. So the sorts of conventions and practices that you see today (an apparently we, too, are engaging in) were initially created for good reasons that are inapplicable today.

A rant about download hashes

And diving even deeper into this digression, there was a really interesting paper presented at ACM CCS 2018, _Toward Usable Checksums. It really was a fine piece of research, but in my view it recommended actions that run against its own findings. Beyond the obvious finding that nobody actually checks these things, and most people don't even know how to, they included this table

As you can see, there isn't a single instance in their sample where the checksum is delivered over a more security channel then the thing that it is a sum of. And oddly enough, there is a case where it is the other way around.

So my conclusion is that although these sorts of checksums once served a valuable purpose, the need for them has been covered by other, better, mechanisms (cheaper TLS, code signing, etc).

Of course GPG fingerprints still have a role, but we could certainly serve up the keys somewhere that is delivered over a channel that is just as secure as the one we are delivering the fingerprint over.

c__

Hi @jpgoldberg,

Sorry about the delayed response, I forgot about this.

Thank you for raising the issue internally!

Totally agree with you on some common historical fingerprint publishing behavior not making sense anymore, including the rant (in most cases). (There are nitty and technical reasons publishing a secure digest over TLS might continue to make sense, especially for consumption by programs or maybe even software redistributors like Linux distributions, rather than by end-users. Then there is the whole issue of GPG short keys being short enough to be collided trivially.)

Thanks!

AGAlumB

Likewise, thanks for bringing it up! It's definitely a complex -- and interesting -- topic. Happy holidays! :chuffed:

c__

Happily new year! I see op 0.8.0 is still published with a GPG signature (https://support.1password.com/command-line-getting-started/). Is the GPG pubkey distributed by HTTPS on agilebits.com anywhere, or still only by 3rd party keyservers?

Would you consider switching from PGP to, e.g., minisign (Source)? (It is similar in spirit and functionality to the older OpenBSD signify utility, but is portable to all platforms 1passwordX is and uses the well-regarded libsodium NaCl derivative to implement the cryptographic operations. There is a Golang version, if that helps.) Minisign is well-regarded in the cryptographic community, while GPG is not.

felix_1p

Thank you @c__! I will raise that with the team.