Nikos Mavrogiannopoulos nmav@gnutls.org writes:
On Tue, 2014-11-25 at 07:28 +0100, Niels Möller wrote:
And what does cipherno represent here? Just "AES", or does it imply a key size and/or a mode of operation too?
Yes, something like AES-128-CBC.
I see. Makes sense.
I don't have ecb mode at all since it is not used by TLS (or any other protocol). Just cbc, and gcm for now.
Also makes sense. Then you probably should use the nettle_cipher_func type as little as possible. Rather, something like
struct aes128_cbc_ctx CBC_CTX(struct aes128); nettle_crypt_func aes128_cbc_encrypt;
/* If you're going to call this function via a generic function pointer only, there's no gain to have a precise context type, it can just as well take a void * argument and cast internally. */ void aes128_cbc_encrypt (void *p...) { struct aes128_cbc_ctx *ctx = (struct aes128_cbc_ctx *) p; CBC_ENCRYPT (ctx, ...); }
const struct gnutls_cipher aes128_cbc = { .name = "aes128-cbc", .size = sizeof(aes128_cbc_ctx), .encrypt = aes128_cbc_encrypt, ... };
And to make the contexts structs exposed to library users more self-contained, they can have as first element an "is_a"-pointer to the corresponding gnutls_cipher, followed (pointer, or directly in the same object) by the internal cipher-specific context. I guess you already do something a bit like that?
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.
No it will not.
So nettle-3.1 must have a new soname, if it's going to use versioned symbols (which I'm leaning towards doing).
I think my patch addresses that for both.
I think it lacked a linker script for hogweed, with symbol version tracking libhogweed's major version rather than libnettle's.
What I now realize is that that mini-gmp mpz_*, gmp_* and mpn_* symbols are not exported in the script that I sent. They could be put unconditionally there, or via a configure variable.
I think it's generally a bit dangerous to make shared libraries with mini-gmp (the result is not promised to be binary compatible with regular builds). Anyone trying that really needs to know what he/she is doing. So I think a sensible default is to disable hogweed symbol versioning in that case, and possibly have a configure option to explicitly specify the linker script to use for each library.
Regards, /Niels