I intend to wrap liboath for Python, using Cython. I have several questions:
1] The bindings would be very simple and short. I can send a patch for incorporation into the liboath project. 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. 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. 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. 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? sincerely, Yclept Nemo
