Hacking M2Crypto

M2Crypto = Python + OpenSSL + SWIG

Architecturally, M2Crypto consists of two layers. The lower layer uses SWIG to hook up the OpenSSL C API functions, making these available as Python functions. The upper layer provides Pythonic object-oriented interfaces to the lower layer. The naming convention for the lower layer matches OpenSSL's API naming closely; this means that, most of the time, you can refer to OpenSSL's documentation to figure out what a function in the lower layer does.

As an example, suppose you want to implement the functionality of "openssl pkcs12 some-specific-operation" in M2Crypto. Here's how:

» Look in <openssl>/apps/pkcs12.c for the parts that implement some-specific-operation. Note the structures and functions used. See <openssl>/include/pkcs12.h for the definitions of said structures and functions. Check OpenSSL's docu for those functions.

» Now create the SWIG interface file <m2crypto>/SWIG/_pkcs12.i. Add whatever glue code is necessary so that

• Python and C code can pass pointers (treated as opaque cookies) to the identified structures back and forth,
• Python can invoke the C functions,
• the C functions can raise Python exceptions and perhaps callback into Python.

» Next create the file <m2crypto>/M2Crypto/PKCS12.py. Add Python wrapper classes to the pointers to structures; the glue functions that work on said pointers become methods of these Python OO wrapper classes. Add utility functions at the module level for the convenience of the module user (i.e., the application programmer). Write unit tests along the way. Write doc strings! ;-)

» Send patches; unified diffs, please.

I accept all patches. If they fit in easily, I put them in. If they don't I stick them in the contrib/ directory with a README. If I appear to be sitting on your patches, maybe it is because your patches scare me into re-evaluating my aforementioned liberal patch policy. ;-) Or, maybe I am just sitting on them. Prod me.