alexmreis
commented
11 years ago Think we should treat mirrors and trust as 2 separate issues. Like the decentralised idea in your proposal.
Open Geal opened 11 years ago
alexmreis
commented
11 years ago Think we should treat mirrors and trust as 2 separate issues. Like the decentralised idea in your proposal.
nyarly
commented
11 years ago Especially given the PGP is a non-starter, I don't see what this gains over a (Ruby-community) web of trust. Certainly, some users are going to be de-facto notaries - they'll hold well-known keys that are used to sign many gems.
That said, it might not be a bad feature of a new WoT system to allow for users advertise their willingness to be trusted as a key signer or gem signer.
Geal
commented
11 years ago This does not necessarily need GPG. By borrowing some code from Krypt, we could handle signature verification easily.
The problem with a Web of Trust is that it pushes the decisions onto the end user. People have different notions of the trust levels: if Alice says that she trusts Bob's key at 7/10 level, what does that mean for Charlie? Moreover, what happens when there is a signature mismatch, or a user changes its key? Do you expect that every Ruby developer in the world be able to navigate the Web of Trust and decide if accepting the new key is OK?
With the notary system, we reduce the need for big cryptography libraries on the client side, and notaries handle the trust management and the communication with developers. And between developers and notaries, I can very well see a Web of Trust, because the number of actors will be limited (compared to every Ruby developer now and in the future).
nyarly
commented
11 years ago What I'm saying that the idea of notaries is one that could be managed as a convention on a WoT.
As for the cryptographic elements, it's sounding like it the crypto isn't provided by stdlib's OpenSSL, it ain't happening. Signing things remains a possibility, though, as OpenSSL provides that.
Also, I'd caution from confusing the general idea of a WoT with the PGP implementation. A special purpose WoT could basically ask "who do you trust to sign gems?" and "who do you trust to endorse other gem signers?" The default answers to those questions in rubygems could be "this list of notary agencies" and "no one else." Which would still allow paranoid users (or those with special needs) to configure that separately.
Geal
commented
11 years ago Ok, I was a bit confused about your definition of WoT, and now it's clearer. So, yeah, I agree, notaries are just one part of that.
The fundamental idea is to delegate the trust to someone else (because it's easier for everybody), but not a unique organization (because it's safer and more robust).
nyarly
commented
11 years ago I agree that would be a good practice and convention, and that tooling should support and encourage it.
Before I explain my proposal, I'll list the main points I want to address:
So, like package managers for Linux distributions, there are really two parts: the package downloading system (HTTP, FTP, DVD delivered by snailmail) and the key management.
About the key management
I am not a fan of a central CA, because it introduces bureaucracy and cryptography in a single point of failure. That's not a good mix. And in the eventuality of a fork -because soon after you introduce some sort of commitee, there might be a fork- developers will need to register certificates in both the fork and the original project.
SSH style and Web of Trust systems put too high a load on the end users. I can't expect from people to decide the trust level on each and every gem. That is already a failure in GPG (because everybody has its own definition of the trust levels).
Trust agility
I would like to propose a system like Convergence: you just have to decide on a list of organisations (let's call them "notaries") to delegate your trust. They will be the ones verifying identities and publishing lists of gems. The gem list could be a file of that format:
With the gem's name, the version, and a hash of the gem. This file would be signed with the notary's public key. Adding a notary would mean adding its address and public key to the configuration. (I am aware of the restrictions on GPG and OpenSSL, but couldn't we at least get DSA and SHA1 in pure Ruby?)
That way, end users don't have to manage the trust and identity for every gem, but they could run their own notary and verify everything if they want. We are decentralizing the trust, without the pain of managing a Web of Trust. Developers can still sign their gems for additional security, but there is a very limited set of people burdened with the key management.
Revocation can be handled easily: you just need to update the gem file for every notary. Notaries can be compromised, but if you divided your trust between multiple notaries, you can be warned that there's a mismatch between versions of a gem.
We should decide on a common way for developers and notaries to communicate. This could be GPG signatures, hash uploads on a web server (with strong authentication, etc), or whatever else, as long as everyone can get access to the info fast.
Note that I did not talk about handling the gems, just the trust.
About file management
A big concern for me is the unavailability of repositories like rubygems.org in case of a hack, datacenter outage, or volunteer exhaustion (cheers, people, you're doing an awesome work!).
Once we get the trust management part out of the picture, downloading gems from trusted source is not a problem anymore: we can verify them once they get to our machines.
That way, people could run their own servers to distribute the gems, and the list of these servers could be published. We could choose where we download gems, like Linux distributions. We could run local gem servers that rsync from the public ones, to reduce the loads on corporate networks. We could download our gems by torrent \o/
More seriously, by decentralizing the file servers, we reduce the load (in bandwidth and server cost) for the volunteers, and can provide faster and robust gem downloads for everyone.