CA key management for gem authentication is “overkill” with no real benefit.

[smile-on]

This issue to discuss reasoning to go with any Trust Authority solutions (CA, WOT) and full scale security just for gem authentication.

First, look at practical validation procedure offered by king of popularity Apache web server release destribution. Validation facts: 1.Public Keys are published with no CA http://www.apache.org/dist/httpd/KEYS 2.Import of public key is done without validation (trust) in public repository (CA) 3.Verification of release is finished at point, the signature is good. => package is not tampered. 4.CA is optional and faked by “PGP Public Key Server” Don't think they did not considered CA. They did and found it no value in free software practice. “A good start to validating a key is by face-to-face communication with multiple government-issued photo identification confirmations.” Most noticeable final statement on Apache validation procedure: “Alternatively, you can verify the MD5 signature on the files.” => that sounds like PK/CA trust is not an actual necessity in real life for most Apache users.

Second, I encourage you to open your mind and watch Ben Smith’s presentation than read article on “unsuccessful spy” which is a quite recent story when Canadian national intelligence agency CSIS has ignored its own policies and did not performed security audit. In that story a leak of hundreds documents with top security level was done by a person with 100% true authentication but been not security audited at scheduled time.

What I am trying to tell here is that from security prospective installing someone-else code is way different from running online payment transactions. Trust at code installation looks more like a trust to that spy. You know his identity at 100% and it does not matter much unless you also done periodical security audit. You simply can NOT replace security audit by running CA. Wake up!

[tarcieri]

Here are the things I like about CAs (although I do not dispute that it's probably overkill):

• Airgaps the private key: By requiring manual intervention, the key can be kept offline, and therefore far less susceptible to attack. Together with a passphrase on the key (and if you're really paranoid, Shamir) it should be fairly effective at preventing private key compromises. This also prevents active attacks, as the key is offline. I don't think anyone would dispute the value of this.
• Least authority gem publishing (verified cryptographically end-to-end): Issuing certs that limit which gems people are allowed to publish diminishes the attack surface of malicious gems, most likely by compromising the signing key of one of the gems in the bundle. To compromise a host that deploys via bundler, you'd need to publish a signed gem that's actually in the bundle, as opposed to today where if you can hack RubyGems and compromise any gem that's in the bundle you have owned the host.

Those are the two biggest reasons. I buy your general argument that identity verification doesn't really help here.

[smile-on]

How about those existing unsigned gems. If all that developer wants to know is old good release hike v1.2.1, that he checked by himself, is still un-tampered and safe to install in production at local "Landscape guru" company as he finishes the project?

[tarcieri]

Those existing gems are a problem for any scheme. That said, I think the easiest solution is to have RubyGems themselves initially sign all "known good"(ish) gems so every gem has a signature to begin with.

[grant-olson]

The apache software foundation doesn't have 50,000+ packages. If they did, their approach wouldn't scale. OTOH, rubygems.org does nothing to examine the code in any given gem, so their CA status does nothing to prove that the code is safe and secure. What it would do is verify that the code you get from rubygems.org was published by the author, as recognized by rubygems.org.

One subtle thing that is confusing when people first start using the WoT is the term 'trust'. It is not saying that a person is 'trustworthy'. It is saying that to a reasonable degree of certainty, you can trust that this actually is the key that belongs to the entity in question.

My current work project has 450+ gems. Individual validation and signing on my own doesn't scale. With a CA I can at least get a baseline that the gems I'm getting aren't compromised per some specific parameters. Not perfect by any means, but it's a good start.

[smile-on]

1. With a CA I can at least get a baseline that the gems I'm getting aren't compromised per some specific parameters. You will get same promise "code is as it was published" with DS as well. Even for those unsigned gems.

2. DS would allow you and anyone who DID check code in some gems to be sure what he is using.

I kind of getting why we can not hear each other. THE BIG problem has two parts:

• rubygems.org needs a better way of authenticate code been uploaded by registered owner (offline PK is good)
• developers need a trust that even if rubygems.org hacked they still know what gems are safe. With reach user interface hack at rubygems.org is quite realistic.

I do not object you guys running toward first goal, just surprised that needs of regular ruby developer is not fully recognized.

[smile-on]

to tarcieri 1) > RubyGems themselves initially sign all "known good"(ish) gems so every gem has a signature to begin with. I would not consider it as a good. Why should I trust a single guy / company to monitor whole gem community. Single point of failure is not good by design. Just imaging.. your rubygems.org admin go browsing from his laptop that is used for ssh access to rubygems.org. It was hacked and hacker gets silent access to rubygems.org. Now hacker may tamper old gem and reissue signatures.

2) I just noticed stress at "easy to begin with". What is so difficult to begin with DS?

P.S. nothing personal, just business.

[tarcieri]

@smile-on I'm talking about a one-time process to grandfather in the existing unsigned gems before RubyGems would begin requiring signatures for new ones.

This could be done offline with an airgapped master key. There is little chance of compromising a machine in this scenario.

This is a problem any scheme has to address. The CA scheme has a solution. Does yours?

[smile-on]

@tarcieri 1) DS is not against of signing gems. It is actually benefiting from that. Please do so. 2) Yes, DS will generate signatures for all gems hosted at rubygems.org and any other repository (Free bonus). It does way more. As I mentioned it works toward second point (developer's need) - no single point of trust. rubygems.org can use DS as independent source of audit that nothing wrong has happened in the company security model. Kindly read DS solution page on wiki.

[tarcieri]

So what you're saying is you have no further arguments against CAs, and are here just to talk about how awesome your solution is?

Can you please close the issue then?

[smile-on]

I did not mean this conversation to become personal. All I want is to bring your attention CA is not solution for the BIG problem as I see it. DS will require very little effort on rubygems.org side and not against of signing gem by repository issued key. The benefits are mutual in eliminating single point of failure. Why not cooperate?

BTW I also opened another issue for critic on DS. I am seeking for critics on DS, not show casing. Don't take it personal.

[tarcieri]

For those of you who are actually interested in the practical security issues surrounding CAs, CAcert has a nice writeup on the history of attacks on CAs in general:

http://wiki.cacert.org/Risk/History

[zachaysan]

Quoting @smile-on:

What I am trying to tell here is that from security prospective installing someone-else code is way different from running online payment transactions. Trust at code installation looks more like a trust to that spy. You know his identity at 100% and it does not matter much unless you also done periodical security audit. You simply can NOT replace security audit by running CA. Wake up!

Quoting @grant-olson:

One subtle thing that is confusing when people first start using the WoT is the term 'trust'. It is not saying that a person is 'trustworthy'. It is saying that to a reasonable degree of certainty, you can trust that this actually is the key that belongs to the entity in question.

I've been thinking for some time that we need a general WoT for developers that incorporates identity-trust as well as ethical-trust. If it weren't fraught with gaming and political concerns I'd also advocate for a competence-trust component of the WoT, but LinkedIn skills gaming has convinced me that that's a fools errand.

When it comes to @smile-on's original point about CSIS missing gaps, yes it is true that the individuals in a web of trust need to be trusted, and it is true that trusting a developer is more like trusting someone with clearance than trusting a financial transaction to go through, but it is also true that most entities don't have Canada's top secret documents. Even the Ruskies only acquired the ones that were available to the trusted party. What a WoT would solve isn't a the code supply chain completely and we shouldn't pretend that it does. But what it does do is significantly raise the bar for a casual actor.

Security is about layers and degrees of trust, not about absolute certainties. We get in trouble when we forget this.

Further, we can organize critical packages to require multiple signing parties before the package goes live and we can limit daily downloads for packages that choose not to incorporate strong enough defences. The core challenge here isn't technical, it's incentives and political will. I'm sure if @wycats or @dhh made this a priority and called for proposals and action it would happen. But without a figurehead, this vulnerability is going to continue to be as widespread as it is.