On Mon, 2014-11-24 at 21:39 +0100, Niels Möller wrote:
- cbc.h:
cbc_encrypt and decrypt use const void* as first parameter. That is, it cannot be wrapped over a function that works for cbc_encrypt as well as gcm_aes_encrypt (the latter doesn't use const). Without casts that is.
Overall, what I didn't like it that the new cipher API required more code to wrap around it.
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()
So within the cipher_init I am using a big switch() to the various algorithms. With the split I need more switch cases for the different algorithms (camellia128,camellia192,camellia256) rather than one for camellia.
gcm_encrypt uses const void * and nettle_cipher_func, just like cbc_encrypt. While the struct gcm_aes_ctx contains both the aes key (constant after key schedule) and per message state, and hence has to be non-const. And it's not much different to if you use struct cbc_aes_ctx CBC_CTX(struct aes_ctx, AES_BLOCK_SIZE);
Does it really matter to differentiate? I mean in my code I wrap stream aead, and block ciphers equally, and having a different function pointer for each would mean that I will use function casts (which are horribly dangerous if the API changes and I don't notice).
(said that I think I'll separate the AEAD ciphers after having seen the horrible CCM mode, and may only allow packet encryption with them).
- libhogweed soname:
libhogweed has the same soname with 2.7.1, so applications crash if they are linked against nettle 2.7.1 and 3.0 is installed (that is because hogweed links against libnettle.so.5).
He intention was that nettle-2.7.1 uses the sonames "libnettle.so.4" and "libhogweed.so.2", and that nettle-3.0 bumped both numbers, to libnettle.s0.5 and libhogweed.so.3. Was that somehow messed up in the release?
I was mistaken it seems. It is indeed libhogweed.so.3 that I see in 3.0. For some reason evolution was linking with it though and wouldn't run after installing it.
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.
It may make sense for both libraries to share the same so version.
I think it is likely that there maybe incompatible changes affecting only nettle or only hogweed. So I think it's best to keep them independent.
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. Symbol versioning would save the day there too though :)
regards, Nikos