CPAN|PR Challenge
January 2015 — or — Finding Fixes for Crypt::OpenSSL::X509

Ringing in the New Year, I joined the CPAN Pull Request Challenge, a loosely organized (ragtag) group of F/OSS enthusiasts of varying levels of Perl expertise who are trying to Make CPAN Better™, one pull request at a time.

The premise is simple enough: every month, neilb (the guy in charge) fires up a script that works through CPAN modules / dists and semi-randomly assigns each participant a module for the month. Participants then have the rest of the month to find one or more ways to make their module better. Work is done, and a Github pull request is submitted to get the changes merged in by the current maintainer.

I got Crypt::OpenSSL::X509, a Perl XS module that glues together libopenssl's certificate handling (the purview of openssl x509 ...) and presents a familiar, more Perl-y way of parsing certificates.

I believe (but cannot directly substantiate) that the module made it into the candidate list for the challenge because of the following:

  1. Github Issues: there were 6 open issues
  2. Reverse Dependencies: 11 other CPAN dists use require this one
  3. Few Recent Releases: 1 in 2014, 2 in 2013, none in 2012

When I got the assignment email, I was pretty happy; I love writing C code, XS code is (in my experience) less well-maintained than straight-up Perl, and I had always wanted to tinker with perlguts.

Before I got started writing some code however, I wanted to figure out what needed to be done, and coordinate with the maintainer to see what they would like to see done. The timeline of events looks something like this:

Let's talk about the Github issues for a moment.

The most promising, #28, was an ask for the -nameopt semantics of the openssl binary to be ported to the Perl module. The requester had worked around the issue by shelling out via backticks to just run the command and get the output.

The others were not well-suited to something like the Pull Request Challenge; two of them were reporting problems compiling the XS module on Solaris/SPARC platforms. Others dealt with UTF-8 issues that were causing the tests to fail (but not on any platform I have access to). I'm sure these types of very platform-specific issues are confined to XS modules, and may in fact just come with the territory.

This is the email I sent Dan (the maintainer):

My names is James Hunt, and I'm participating in the 2015 CPAN Pull Request challenge (

I got Crypt::OpenSSL::X509 as my module/project, and I wanted to reach out to (A) introduce myself and (B) start a conversation about what needs to be done (if anything) to make the module better.

As I said, I'm James, and I hack Perl for a living. I'm jhunt on github and JRHUNT on PAUSE. My website is

There, (A) complete!

As for (B), I took a look at the issues on GH -- most of them seem to be about platforms I don't have access to (OSX / Solaris). The nameopt feature request seemed interesting, but I wanted to get your feedback on the direction you want to take with the module before I start writing any code.

Thoughts? -jrh

Less than a week later, Dan replied and suggested that I go forward with the nameopt thing, and urged me to contact the original requester to get more information.

After a dive into the OpenSSL codebase (never as fun as it sounds), a few conversations with the original requester on Github, and two false starts on a pull request, #28 got closed without a single line of code being written.

A little more exploration of what Crypt::OpenSSL::X509 led me to the entries() function of X.509 name objects (both Issuer and Subject names). In the end, everything the requester needed to do it in Perl was already in the module! I commented on the issue, with some working Perl code that did what the requester had wanted to do in the beginning, and emailed Dan that he could close the issue.

Issue closed! No work necessary!

No Pull Request for James…

I still feel like I helped out. Looking into the more platform-specific issues taught me a lot about how CPAN smoke testing works, and managed to get two more issues closed. The dist now only has 3 open issues on Github, down from 6 — that's a 50% reduction in bugs!

Yet the challenge still stands.

I may have to settle for an official 'loss' on this go-round, and hope for a less well-maintained piece of software the next time around. In the meantime, I'll be reading this and this, and hanging out in #pr-challenge on looking for inspiration.

James (@iamjameshunt) works on the Internet, spends his weekends developing new and interesting bits of software and his nights trying to make sense of research papers.

Currently working on Bolo.