Nikos Mavrogiannopoulos n.mavrogiannopoulos@gmail.com writes:
An approach for Ron to overcome the specific problem could be to use wrappers over nettle which hide the details, such as the gnutls functions (e.g., gnutls_mac_fast etc.).
If gnutls has sutable wrappers for umac, that sounds like an easy solution, at least until needed interfaces are added to nettle.
The more long term question, is should nettle be striving to provide an ABI? If not, it could transform to low-level library gnulib or ccan are (i.e. like a copy-lib)... or alternatively, if yes, provide a high level stable API which hides details and the ABI is easier to provide.
We could add a thin layer of functions involving only opaque pointers, byte strings, and ints. If we really want, it could be a separate .so-file, which could have an ABI more stable than nettle's. But I'm not sure if that's really solves Ron's problem of using the functions without depending on the header file. E.g, say we add a function like
void *mac_ctx_new(enum nettle_mac_algorithm);
and it's called like
void *umac_ctx = mac_ctx_new(NETTLE_ALGORITHM_UMAC);
And then the python glue loads libnettle.so, and wants to make this function call. How would it find the numeric value of NETTLE_ALGORITHM_UMAC? Would it duplicate the definitions in the C header (which is ok, since these constants are (i) part of the ABI and supposedly stable, and (ii) not architecture dependent), or would we need some interface using plain strings to identify algorithms?
Happy holidays, /Niels