rubygems-trust / rubygems.org

The Ruby community's gem hosting service.
https://rubygems.org
MIT License
16 stars 2 forks source link

PGP/GPG as a Ruby(Gems) dependency is a non-starter #9

Open tarcieri opened 11 years ago

tarcieri commented 11 years ago

Via @evanphx, one of the principal maintainers of RubyGems:

https://twitter.com/evanphx/status/298201886908088320

"You can tell them [GPG is] a nonstarter."

There are a number of hard problems with shelling out to GPG to authenticate gems, most notably that every Ruby implementation (e.g. JRuby, rbx) will need to ship GPG or integrate it into their existing codebase.

Also: Windows

Sure, Linux distributions use GPG for this purpose. Ruby (in the form of multiple, independently maintained implementations) isn't a Linux distribution. It has different concerns. Among other things, Ruby runs on multiple operating systems, which makes using a tool like GPG much harder that, say, a Linux distro where the tools are guaranteed by design to run on only that distro.

jstr commented 11 years ago

+1

postmodern commented 11 years ago

This is not really a proposal and more of a statement/opinion.

tarcieri commented 11 years ago

@postmodern it's an issue ;)

pietro commented 11 years ago

Also: Windows

Last time i used windows, many years ago, GPG worked fine on it. Also there's https://github.com/bendiken/openpgp we could organize a fundraiser to pay for code auditing.

tarcieri commented 11 years ago

@pietro the issue is RubyGems must depend on the Ruby standard library alone, and it must support older Ruby versions so adding a native code dependency to the Ruby standard library isn't an option, nor is shelling out to a third party tool

tarcieri commented 11 years ago

@postmodern also note this is an "opinion"... of Evan Phoenix, one of the principal maintainers of RubyGems.

luislavena commented 11 years ago

@tarcieri you can say is my opinion too.

PGP does works on Windows, but it doesn't come out of the box with it and never will. RubyGems and Ruby needs to be self contained.

We (at RubyInstaller) worked hard to get the basic stdlib pieces working so OpenSSL, libffi and others work without issues.

I would say I have no intention on adding a GNU licensed tool to RubyInstaller just to deal with this.

postmodern commented 11 years ago

@tarcieri we should be judging Proposals based on their Security, so that we select the most secure gem signing solution. Shooting down proposals because they introduce a new dependency, version requirement or license is counter productive at this stage. Also, referencing opinions of RubyGems maintainers is an appeal to authority.

luislavena commented 11 years ago

@postmodern sorry to disagree with you, but I strongly disagree, even if you don't care.

tarcieri commented 11 years ago

@postmodern I think we should be collaborating with the RubyGems maintainers. Are you suggesting otherwise? I think that's a really, really bad idea.

Regarding security, what does GPG bring to the table exactly in that regard that's an improvement over the existing RSASSA signatures being used in RubyGems? People point to key servers... is that all people are trying to gain here? And is that even a good idea?

We have to balance security with practicality. If we really want the best crypto available, we should be using Ed25519 and RbNaCl, but even I think that's a bad idea.

postmodern commented 11 years ago

@tarcieri we are collaborating with the RubyGems maintainers. However, we should evaluate all feedback equally.

@luislavena Note that I said "at this stage" ;) Once the Proposals have been judged on Security, then we can judge them on how feasible they are to implement.

tarcieri commented 11 years ago

@postmodern I'd argue GPG in this application does not offer any tangible security benefits over RSASSA via Ruby stdlib/OpenSSL

postmodern commented 11 years ago

@tarcieri feel free to argue against GPG in issue #6. :)

pietro commented 11 years ago

@tarcieri thanks for the clarification. Is there any documentation on which versions of ruby rubygems has to be compatible with? Specficaly how long will support 1.8.7 after its EOL.

@luislavena distributing a compiled version of GPG shouldn't affect the licensing of any other software also distributed by RubyInstaller.

evanphx commented 11 years ago

I have every intention of rubygems supporting 1.8.7 for many more years. But it's really not 1.8.7 that is the issue, rather it's 1.9.3 since it does not include any PGP things. I'd imagine we'd support 1.9.3 for minimum 5 years (could be more like 10).

postmodern commented 11 years ago

@evanphx I would highly recommend against supporting 1.8.7 after it goes EOL. Users should be encouraged to upgrade to a properly maintained version of Ruby, in order to receive important security updates. Also it makes development a lot simpler.

evanphx commented 11 years ago

There are far too many people still on 1.8.7 to foresake them. If we intend to drop 1.8.7 support, we have to communicate it well in advance (at least 6 months).

luislavena commented 11 years ago

distributing a compiled version of GPG shouldn't affect the licensing of any other software also distributed by RubyInstaller

For example, gpg4win: http://www.gpg4win.org/license.html

I would require to bundle also gpg4win sources to distribute along RubyInstaller, or to comply with GPL, will require to have a clone/copy of the source available upon request.

I would not be able to delegate that to the official repository/download location of gpg4win.

I already deal with a lot of licensing crap in relation to Ruby/RubyInstaller/OpenSSL/Tcl/Tk that I don't want to add another one, specially with GPL software.

I would rather use RSASSA as is right now and use my code-signing certificate and tell people that is serious about their software to get one.

grant-olson commented 11 years ago

I'm one of the people who wants OpenPGP. And believe it or not I'm entirely sympathetic to @evanphx position that gpg shouldn't be bundled into rubygems.

But gpg is only a hard requirement if OpenPGP signing and verification is mandatory. Is it really practical to expect that one day a switch will be flipped and we'll go from no gems signed to all gems signed and mandatory verification of all gem installs?

I don't see the problem with starting from a place where the 1-in-10 (or more likely 1-in-100, 1-in-1000, or 1-in-10000) developers who actually care about authentication may have to install gpg if it's not installed on their current OS. And what's wrong with spitting out "Sorry but this feature requires blah..." and quitting when someone doesn't have the requisite software installed and adds a --verify switch?

The problem whole problem of trust is not "we just need to verify an RSA signature." That part is easy. The issue is actually authenticating keys and building up trust chains. It's a lot easier to start the process of doing that with OpenPGP and incrementally improve than to build the entire infrastructure needed for X.509 over the course of months and hope people actually use the system.

evanphx commented 11 years ago

Hi Grant,

The intention is to devise a system such that, yes, we can flip a switch and say "rubygems only accepts signed gems". That is the only way to allow casual ruby users to be verifying gems.

Additionally, it's the casual ruby user (the vast majority) that I'm thinking about most. Using OpenGPG to build a WoT simply does not work for a casual user because they have no ability to build a WoT that is going to cover all gems.

A WoT system as you described is possible in rubygems 2.0 using metadata and rubygems plugins, but it simply can't be the primary gem verification system.

grant-olson commented 11 years ago

On 02/09/2013 12:43 PM, Evan Phoenix wrote:

Additionally, it's the casual ruby user (the vast majority) that I'm thinking about most. Using OpenGPG to build a WoT simply does not work for a casual user because they have no ability to build a WoT that is going to cover all gems.

You can build a CA in OpenPGP if you want. See the PGP Global Directory for a real-world example. It would be just as easy to distribute a master OpenPGP signing certificate with rubygems as an X.509 one. You don't have to involve a casual user in key-signing parties, getting into the strong set, etc.

Regarding the other point, yes if this is intended to roll out globally to all users with mandatory enforcement, gpg is clearly not an option.

postmodern commented 11 years ago

In order to ensure that all gems are signed, would we open up abandoned gems and sign them with some default key (x.509 or PGP)? This would force rubygems mirrors to re-sync.

evanphx commented 11 years ago

That's one option. Another option is to allow for external signatures and just post them, signed with a Rubygems Maintainer cert.

smile-on commented 11 years ago

Running real CA is not a volunteer business. And needs to be $/per cert request. How does CA will ensure code signed with issued certificat is not compromised? Developer pc can be compromised. It needs audit of code or just blindly trust a Rubygems Maintainer, right?

My personal preferences is a mix of gem signed with a Rubygems Maintainer cert with trust centres that double sign gems after code review or just blindly duplicate certification for some trusted rubygems maintainers. Especially if those trusted maintainers are full-timers of "some-well-known-company". ;) That would allow making RubyOnRails releases without waiting on every gem to be signed by maintainer but by doing code review and issuing signatures on particular versions of used gem in RoR trust centre. Than anyone who is willing to trust RoR trust centre may install it without blindly hitting YES on every gem key. + an gem installation tool may still doublecheking signatures against a Rubygems Maintainer certificate. Than if I wish to put some package that has not been validated by trust centre or it is just a new version of gem that is not yet pass formal validation on trust centre I can do that without over-killing demand to trust centre.

I'll clarify my point on wiki.

Slav.

On Sat, Feb 9, 2013 at 10:29 PM, Evan Phoenix notifications@github.comwrote:

That's one option. Another option is to allow for external signatures and just post them, signed with a Rubygems Maintainer cert.

— Reply to this email directly or view it on GitHubhttps://github.com/rubygems-trust/rubygems.org/issues/9#issuecomment-13343858..

FooBarWidget commented 11 years ago

I'm also on the PGP side. But that aside, it's now been a month since the last discussion comment. Is there any progress towards an official system?

headius commented 11 years ago

Any solution that doesn't work on a vanilla MRI install with no external requirements is a failure...full stop.

FooBarWidget commented 11 years ago

Ok, I get that, but then what is the solution and what's its current progress?

tarcieri commented 11 years ago

@FooBarWidget TBD. The RubyGems people have been busy with the 2.0 release. Now that that's out the door, that can loop back to the question of gem signing.

The short answer is probably: expanding the existing X.509-based gem signing solution already implemented in RubyGems. X.509 is widely deployed for the purposes of code signing (more so than GPG, afaict) and can be implemented in terms of the OpenSSL library already in the Ruby standard library.