Nikos Mavrogiannopoulos nmav@gnutls.org writes:
Can you give some example of what you're doing?
I provide an API such as: ctx=cipher_init(cipherno, key) cipher_encrypt(ctx, data) cipher_decrypt(ctx, data) cipher_deinit()
And what does cipherno represent here? Just "AES", or does it imply a key size and/or a mode of operation too?
Does it really matter to differentiate? I mean in my code I wrap stream aead, and block ciphers equally,
With "block ciphers", I imagine you include ECB mode, not just CBC and CTR and the like?
In that case I think you need to pass contexts around as always non-const. It's not entirely clear to me how much casting there will be of the function pointers, hopefully it can be isolated.
But some casting is needed somwehere, if one is going to assign both aes128_encrypt and camellia128_crypt to variables of the same type. Within nettle, that casting is done in the initializers for the various nettle_cipher structs.
And the way I recommend (but maybe that doesn't work for you?) is to use an array of constant structs, similar in spirit to struct nettle_cipher and struct nettle_aead, rather than a big switch.
As far as I understand, the versions symbols thing should help. I guess sonames have to be bumped again when version symbols are introduced?
Not needed. But the version with the symbols will be binary incompatible with the previous one, so it may make sense to bump the soversion again to make that clear that they are incompatible.
Can a program linked with nettle-3.0 use a nettle-3.1 library with versioned symbols at runtime? If not, we must have another soname bump.
Would that independence work in practice given that lighoweed is linked with libnettle? I mean if you only bump only nettle, there will be a competing libhogweed with the previous version of nettle if both are installed.
I don't understand all possible cases. But I think it's nice if you don't have to upgrade a program using only interfaces from one of the libraries, just because you upgraded to a newer version of the nettle packages, and the other library had an incompatible change.
Symbol versioning would save the day there too though :)
If we introduce symbol versioning, it seems good to do it for both libraries at the same time.
Regards, /Niels