Yclept Nemo <[email protected]> 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
