Re: [pyOpenSSL] CRL & PKCS12 patch

[Jean-Paul C. <ex...@di...>]

On Thu, 09 Jul 2009 12:39:48 +0100, Phil Mayers <p.m...@im...> wrote:
>All,
>
>I've written a little CLI-based micro CA in pyOpenSSL, but I needed CRL
>support since Vista insists on the CRL be in place for certain types of
>certs (e.g. SSL)
>
>I had to forward-port the existing CRL/PKCS12 patch, which was not hard
>but not huge fun...
>
>What can I do to help get this patch in mainline?

Hi Phil,

Thanks for volunteering.  I don't know when I would have gotten to this.
Probably not soon. :)

>I understand development is now Launchpad/bzr-based; this is unfortunate
>since I apparently have a cognitive block that causes me to fail utterly
>in driving both tools - but I'm quite capable of coding, including (I
>hope) writing the unit tests and so forth.
>
>If someone can give me a quick pointer as to what is desired, I'll have
>a crack at it.
>

Looking at <https://code.launchpad.net/pyopenssl>, I see that there are
presently four different branches related to either CRL or PKCS12.

  lp:~exarkun/pyopenssl/pkcs12-crl
  lp:~arnaud-desmons/pyopenssl/pkcs12
  lp:~rick-fdd/pyopenssl/pkcs12_mod_and_export
  lp:~sebvieira/pyopenssl/pkcs12-crl-0.8

This is a rather unfortunate state.  Which patch did you port forward, and
what did you port it forward to?  Of the above branches, I only really
know about the first - it's a branch I created a long time ago and only
applied Arnaud Desmons' patch to.

There are a few things beyond what the original patch did which you can do
to help get it landed in trunk:

  * File a ticket!  Right now it's not really clear what the goal of all
    this work is.  It has something to do with "CRL" and "PKCS12" clearly,
    but writing down something more specific than that will make it possible
    to figure out what's going on, how the branches that exist related to it,
    and whether or not the goal has been achieved.

  * Review the APIs for sensibleness and general-purposeness.  Do they
    expose the underlying OpenSSL APIs in a way that's generally useful,
    with introduced arbitrary limitations?  As someone who knows a bit
    about CRLs and PKCS12 (I assume - since you wrote a CA ;), hopefully
    this should be easy for you.

  * Add unit tests for *all* new code and for any old code which is being
    modified and is not already tested.

  * Add documentation for the new APIs (doc/pyOpenSSL.tex is the doc source,
    the rest of the files in doc/ are generated).

As far as bzr and launchpad go, it's pretty easy (but I sympathize with your
position - it's too bad we have to know how to use 3 or 4 or more different
version control systems these days).

Maybe I can help a bit.  To start, to get some code to start modifying, you
want to create a branch of something in launchpad.  If you want to try to
apply your updated patch to trunk (which would be ideal), then you want to
do

  bzr branch lp:pyopenssl

This will create a "pyopenssl" directory with the checkout in it.  Then apply
your patch, do your hacking, whatever.  At some point you'll want to put your
changes into version control.  Somewhere under that "pyopenssl" directory, do

  bzr commit -m "<message>"

Or you can leave off the -m to get an editor to write your commit message in.
Repeat edit/commit as many times as you need.  When you think you're done and
you want someone else to take a look, push the branch back to launchpad.
Somewhere beneath that "pyopenssl" directory do

  bzr push lp:~username/pyopenssl/branchname

Replace "username" with your Launchpad username.  Replace "branchname" with
the name you want to associate with this branch.  If you haven't previously
told bzr about your launchpad credentials, you'll need to do

  bzr launchpad-login

first.

And if you'd rather just send patches around, I don't have a problem with
that.

Thanks,

Jean-Paul