Re: [OATH-Toolkit-help] Python Bindings

[Simon Josefsson]

Yclept Nemo <address@hidden> writes:

> I intend to wrap liboath for Python, using Cython. I have several questions:

Yay!  Thanks for working on that.

> 1] The bindings would be very simple and short. I can send a patch for
> incorporation into the liboath project.

Please do.  While most code is C right now, the project is not tied to
the C language.  I would like to provide a Java library as well.  Python
would be nice as well.

> 2] Some C projects are conducive to object-oriented bindings using
> classes and the like. However for liboath I simply intend to make the
> functions in oath.h available to python (with more pythonic
> signatures, of course). Do have any problems with this; possibly it
> would confict with upcoming changes to liboath? I can't really
> visualize exposing liboath as a class, but I would be interested in
> any suggestions.

Speaking from the liboath C design, I suspect it won't change a lot in
the near future.  If some more object oriented interface is added in the
future (which I don't rule out -- adding PKCS#11 support would most
likely require having a context pointer and will thus be more OO), you
should be able to update your python bindings to add a class for those
functions, couldn't you?  So your suggested approach sounds good.

> 3] Libgcrypt manages it state via static variables - there can be only
> one libgcrypt initialized for the entire program. I plan to initialize
> libgcrypt (oath_init) upon loading the python module and I want to be
> sure that liboath doesn't depend on the state of libgcrypt. For
> example, I want to ensure that running several different operations
> (possibly, generating OTPs from different secrets) by interleaving
> function calls will not cause problems with libgcrypt's global state.
> I doubt it would since the only libgcrypt function is "gc_hmac_sha1"
> in oath_hotp_generate(), but I would like to be certain, especially
> with regards to future changes in liboath.

I'm not aware of any issue here, so let's try this approach and see if
it works.  Use of libgcrypt is a bit overkill for liboath since it only
needs HMAC-SHA1.  The Debian/Ubuntu package doesn't link to libgcrypt.

> 4] Since python modules can't be unloaded, oath_done() will never be
> used. Because libgcrypt uses a static state, I can only hope this
> won't cause any problems when importing other python modules depending
> on libgcrypt. I would be happy for suggestions on how to mitigate
> conflicts like this.

I think libgcrypt's approach is that these conflicts must be resolved by
the application, by making sure libgcrypt is initialized correctly.  So
I don't think there is must you can do here.

> 5] Is liboath's usage of libgcrypt thread-safe? The python bindings
> would make it possible to access liboath and thus libgcrypt in
> parallel via python threads. Will this cause any problems and should I
> take any preventative measures in the python binding of liboath?

Calls to oath_init ought to be wrapped in a thread mutex, since it is a
global initialization function.  The HMAC-SHA1 operation is thread safe.

/Simon