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

[tarcieri]

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]

+1

[postmodern]

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

[tarcieri]

@postmodern it's an issue ;)

[pietro]

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]

@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]

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

[luislavena]

@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]

@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]

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

[tarcieri]

@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]

@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]

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

[postmodern]

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

[pietro]

@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]

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]

@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]

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]

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]

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]

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]

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]

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]

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

[smile-on]

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//issues/9#issuecomment-13343858..

[FooBarWidget]

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]

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

[FooBarWidget]

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

[tarcieri]

@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.