search

thoughtbot / gitsh

An interactive shell for git
https://thoughtbot.com
BSD 3-Clause "New" or "Revised" License
1.95k stars 106 forks source link

Releases should be signed with PGP #205

Open georgebrock opened 9 years ago

georgebrock commented 9 years ago

thoughtbot has a PGP key, available at http://pgp.thoughtbot.com

This key should be used to sign releases, so users can verify what they are downloading.

calebhearth commented 9 years ago

That key is for security and few people have signing subkeys. I think it makes more sense for the maintainer to sign the release, and to have a thoughtbot.com UID.

georgebrock commented 9 years ago

If releases are signed with the maintainer's personal key, that will make it harder to change maintainer in the future, or to share the maintainer duties between multiple people. A new maintainer would have to re-sign all of the existing releases, and users who wanted to verify the signature would have to figure out if they could trust the new maintainer's key before they could upgrade.

I'm not sure what you mean by “that key is for security”: it has a hello@thoughtbot.com UID as well as the security@thoughtbot.com UID.

@mike-burns: Any thoughts either way on this?

calebhearth commented 9 years ago

I'm not sure what you mean by “that key is for security”: it has a hello@thoughtbot.com UID as well as the security@thoughtbot.com UID.

Ah, I may have misunderstood its purpose. To my knowledge, however, only Mike and Joe have signing subkeys for it right now.

If releases are signed with the maintainer's personal key, that will make it harder to change maintainer in the future, or to share the maintainer duties between multiple people. A new maintainer would have to re-sign all of the existing releases, and users who wanted to verify the signature would have to figure out if they could trust the new maintainer's key before they could upgrade.

I think that as long as we have a thoughtbot UID and maybe get our key signed by the thoughtbot key, we're good. Any thoughtbotter should be able to sign the release.

On Tue, Jan 06, 2015 at 09:14:21AM -0800, George Brocklehurst wrote:

If releases are signed with the maintainer's personal key, that will make it harder to change maintainer in the future, or to share the maintainer duties between multiple people. A new maintainer would have to re-sign all of the existing releases, and users who wanted to verify the signature would have to figure out if they could trust the new maintainer's key before they could upgrade.

I'm not sure what you mean by “that key is for security”: it has a hello@thoughtbot.com UID as well as the security@thoughtbot.com UID.

@mike-burns: Any thoughts either way on this?

Reply to this email directly or view it on GitHub: https://github.com/thoughtbot/gitsh/issues/205#issuecomment-68896456

mike-burns commented 9 years ago

I'm in favor of using the thoughtbot key (well, a signing subkey) for signing releases. Not everyone needs one, but subkeys are easy to revoke and that they carry the thoughtbot UIDs has some weight.

The encryption subkey is for security, and we'll guard that more closely.

calebhearth commented 9 years ago

The intersection of thoughtbotters using PGP and thoughtbotters maintaining thoughtbot gems seems small, so that shouldn't be much of a blocker.

calebhearth commented 9 years ago

https://www.kernel.org/signature.html

georgebrock commented 9 years ago

I'd be very uncomfortable saying to users “first, set up an in-person meeting with someone from my Web of Trust”. This project is much smaller than the linux kernel, and we can use that fact to simplify the verification process.

I'd prefer to say “releases are signed with this key, which you can verify with this command”. That makes a basic level of verification accessible to any user, but also leaves users free to look for paths through the Web of Trust if they want greater certainty.

calebhearth commented 9 years ago

The verification isn't particularly useful without trust; trusting the thoughtbot company key directly is unlikely as few people have access to it to provide verification; and it is more likely that the maintainer will have a connection in the WoT simply because our developers actively try to connect with more people.

Even if you happen to have the thoughtbot key, it'll be one step further in the WoT from you, and that could be the step that keeps it out of the WoT. If you, for example, had signed it, a person would have a 800% (3 vs 24 unique non-selfsigs) higher chance of having a connection to you based on current sig counts for you and the thoughtbot key.

The more I think about it, the less I think it makes sense to have the company key do anything but sign our keys to provide more validity when it comes to release signing.

calebhearth commented 9 years ago

(Not to mention that, since two of the three signatures have signed your key and the third is you, the thoughtbot key has no chance of having someone able to trust it but not you).

Correction: Joe is a connection that you don't have.

mike-burns commented 9 years ago

To clarify the audience: the only people who should need to trust the tarball are package maintainers.

calebhearth commented 9 years ago

I'm fairly sure I disagree, the reason being that anyone installing (from the tarball) should be able to verify it and potentially trust it.

Can you explain your stance?

mike-burns commented 9 years ago

I expect most people to install from their package manager, which typically has its own verification mechanism. apt uses PGP with a massive Debian web of trust; OpenBSD uses signify; etc.

The people building the package need to verify that they are building based on the correct source and generating the correct checksums, etc.

calebhearth commented 9 years ago

Ah, I follow now.

georgebrock commented 9 years ago

Given the target audience, I'd be happy with @calebthompson's recommendation that whoever makes the release signs it with their own key.

We have maintainers for Homebrew (me), OpenBSD (@mike-burns), and Arch Linux (@cippaciong). It would be good to expand that list to reduce the number of users who have to install from the tarball.