DS solution comments
smile-on opened this issue · comments
Note “Double Signature solution” page has been created on wiki to encourage open mind thinking. Personally I advocate for Double Signature solution (DS) and will maintain DS page with up to date results base on discussions.
In my opinion DS is a good compromise that would allow community to start public gem monitoring. The real world gem authentication have to start with “gem cert” then at dedicated well-known TC that has public keys of trusted authors any new gem release will be automatically validated before signature is issued and notification sent to registered authors. How to build and maintain the trust (CA) is totally separated discussion and I kindly ask to keep it out of this issue thread.
Any comments and critic on DS is welcome in this thread.
The goal is to start going to feasible solution to improve gem security in near time.
How is the authenticity of the initial upload to rubygems.org verified by the system?
@grant-olson the authenticity of the initial upload to rubygems.org (and any other repo) is a business between repo and developer who signed in for account on the repo. DS does not try to stick into this business.
Thank you for a question. I want to stress that DS is not a replacement for signing gem. It just opens an opportunity for someone (community) to have independent and shared audit of code that was uploaded. Even legitimately (100% authenticated) upload may have treads. Right now every one on his own with private repos.
I think maybe a better English term for this sort of service is a Notary Service. You're a third-party that only authenticates that this is the version of package X that rubygems.org was delivering at time Y. A real world notary does the same thing. He doesn't perform any analysis, simply stamps a document to confirm that this is the document he saw at the time.
This might help you communicate the idea better.
@grant-olson I am really enjoying a productive discussion. Thanks for helping me to straight my concerns at Ruby security. I will try to explain my point with help of analogy to notary service.
Notary Service is a very good analogy for TC software that runs in automatic mode than signatures are issued without code audit. However nothing stops third party from manually control signature publishing in TC. This is a very important note and one of the reasons I see a potential feature for DS solution.
Notary service is very important in real life. Especially in third world countries where people under constant fraud threads and trust is a service that is really needed. Home brew “CA” that signs all old packages on the fly without audit and issues new certificates to whoever has login, password does same notary service, no more. Don't get me wrong, this CA is a good thing to do, just don't fall into illusion that its better that notary service. So, both DS and “CA” are notary service, why do one care about DS? DS opens door for new opportunities, especially in field of commercial ruby on rails (RoR) service. For those who try make living out of RoR coding it does make difference. I try to demonstrate this idea in fictional examples below.
Note, science-fiction, not real examples. :)
a) Bit9 starts making code audit of some popular gems and runs TC in manual mode. Lets call this instance tc-bit9. Than every signature on TC-BIT9 would sounds “A general code audit has found no threads. This gem is allowed to be used in production systems of every company who trust Bit9”. Then mid sized coding team may easily get going into the projects of top1000 or government agencies.
b) Independent respectable company runs TC in automated mode that scans its local private gem repository. There is no additional overhead on the company. Lets call it tc-ror.rubyonrails.org. Than every signature on TC-ROR would sounds “rubyonrails.org has found this gem is safe to use in its own business practice. No other promises.” I bet most production RoR installations will include TC-ROR in gem installer configuration. That would refuse automatic installation of some not well known gems (or snicking germs). Client company admin would ask coding company to do audit on those few gems that been used in the project but not listed on TC-ROR.
c) Withdrawal of gems on security concerns (not necessary a compromised one) becomes a reality.
At the moment of publishing RoR security warning rubyonrails.org is free to mark all old releases of actionpack gem as “withdrawn” on TC-ROR. It will not impact those guys who don't care. However any concerned company that periodically runs “gem check” in they RoR environment will see a warning immediately with an options ignore it or upgrade to a new version. A security note will be delivered directly to admin. No need to scan news on web sites, manually copy SHA-1 check sums from web pages. Admins are also become busy some time. :)