Skip to content

Instantly share code, notes, and snippets.

@hsbt
Last active August 29, 2015 14:08
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hsbt/32b2fb67d3023931bae3 to your computer and use it in GitHub Desktop.
Save hsbt/32b2fb67d3023931bae3 to your computer and use it in GitHub Desktop.

openssl maintenance

Hello hello hello!

I’d like to discuss a plan for the future of openssl in ruby. The openssl extension is native to ruby and is used throughout the ecosystem, and internally by RubyGems.

It faces a number of problems, mainly:

Slow development activity, low contribution rate Release cycle by backport release fixes is cumbersome and painful for users

We can solve these by turning the openssl extension into a gem, that is maintained outside the release cycle of Ruby. The major advantage to this ease of upgrades for users, and making contribution more accessible.

To do this we need the following:

Export ext/openssl from trunk to a separate repository Gemify the library, adding gemspec, and version file Host the repository on github.com/ruby/openssl Upload the gem to rubygems.org/gems/openssl Import tagged gem releases directly to the ruby source tree

You can view the current progress of the gem at https://github.com/zzak/openssl

Support

My first concern is existing issues for openssl in the ruby bug tracker. Here are the current stats:

42 tickets assigned to Martin 22 tickets under ext/openssl category.

These tickets should be addressed in the near future between myself, Martin, and other contributors.

Compatibility

Recently, changes to the ruby threading model were necessary to compile the openssl extension outside of the ruby source tree. This means we can install the extension just like any other gem.

The threading changes will be released with Ruby 2.2, and so the openssl gem will only be installable on Ruby 2.2+.

However, we still plan to maintain backwards compatibility with Ruby 1.9, 2.0 and 2.1.

The only difference is that these rubies require the openssl extension to be merged into the source tree and released along with Ruby. Just like we’ve always done.

Release Process

This will change how we release Ruby. Currently when we patch openssl it must be committed to the first affected version (likely trunk) and then backported to older versions, for every single patch that is made to openssl.

With the release process external from Ruby, we can simply import specific releases of the gem extension to affected versions of Ruby when necessary.

As a work-around for users of Ruby 2.2+ only gem update openssl will be needed.

Versioning

After discussion with Martin, we resolved that the existing openssl extension (as we know it today) should become version 1.0.0 of the gem extension.

We are open to suggestions here, but we plan to follow similar policy as semantic versioning for the maintenance of the extension.

For future plans, we’d like to be able to target newer versions of OpenSSL as currently there are a number of hacks in place to support older versions, such as 0.9.x.

Naming

The name should be ‘openssl’ and will need to look into the rubygems.org support team for claiming the name. However, it’s important that the gem name and the require match.

Continuous integration

In order to ensure compatibility with all supported versions of Ruby, we should setup continuous integration and test against them independently.

We can use travis-ci for the builds.

Contributions

In order to increase contributor traffic, I’d like to setup an independent github repository for the extension. This could under the Ruby organization, such as github.com/ruby/openssl. We will need @hsbt to setup the repository and give us admin access for user management, etc.

Eventually, we can move issue tracking to github, but we will keep using bugs.ruby-lang.org for now, since are already a number of existing issues there.

Security

I’m not a security expert, and will need the support of the security@ruby-lang.org team to help regarding openssl security issues as we have in the past. The only workflow difference is how releases are handled. Once the patch is applied to the gem, we will tag the release and import into the ruby source tree (note: before releasing the gem itself) so that we can release all affected versions of Ruby and the gem at the same time.

Feedback

Your feedback is important to this issue and the future of openssl in ruby.

I’ve listed a few of the issues found with the openssl extension, and offer some possible pros & cons to doing this. I hope that you will help me sort out the details, and why this is a good idea!

Thank you for your time and I look forward to working on this with everyone! zzak <3 <3 <3 <3 <3

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment