Crypto pre 1.1-compat #229
Conversation
|
These are the "pre-crypto_compat" changes that are part of #225, in case you wanted to evaluate them separately. |
| @@ -32,7 +32,7 @@ | |||
| */ | |||
|
|
|||
| static int import_BN(BIGNUM **, const uint8_t **, size_t *); | |||
| static int export_BN(BIGNUM *, uint8_t **, size_t *, uint32_t *); | |||
| static int export_BN(const BIGNUM *, uint8_t **, size_t *, uint32_t *); | |||
There was a problem hiding this comment.
This is problematic because old versions of OpenSSL declare BN_bn2bin as taking a BIGNUM * argument instead of a const BIGNUM * argument. Admittedly, it looks like "old versions" in this case means pre-0.9.4, but I wouldn't be surprised if other crypto libraries copied the broken API.
How about deconsting bn in the call to BN_bn2bin?
There was a problem hiding this comment.
I'm confused. OpenSSL 0.9.6 certainly uses const BIGNUM * for BN_bn2bin() [1], so what's the fuss? I mean, if we ever switch to a different library that has a BN_bn2bin which takes a non-const value, couldn't we change at that time?
[1] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6-stable/crypto/bn/bn.h#L344
There was a problem hiding this comment.
and yes, SSLeasy didn't use const here, at least as of 0.9.1b. But is that a concern for us?
There was a problem hiding this comment.
Yes, the const was added between 0.9.3 and 0.9.4.
The reason I was thinking that being compatible with other libraries would be good is that some (libressl, boringssl) are designed as "drop-in replacements" and users might want to drop in such a replacement themselves. But on further consideration... well, it's probably safe to assume that nobody is going to resurrect a broken API from a 17-year-old version of OpenSSL at this point. So don't worry about it.
lib/crypto/crypto_keys_subr.c
Outdated
| goto err1; | ||
| if (import_BN(&(*key)->e, &buf, &buflen)) | ||
| if (import_BN(&e, &buf, &buflen)) | ||
| goto err1; |
There was a problem hiding this comment.
If we goto err1 here, what happens to n?
|
Updated PR with a fix to the memory, but not the de- |
lib/crypto/crypto_keys_subr.c
Outdated
| @@ -180,23 +183,23 @@ crypto_keys_subr_import_RSA_priv(RSA ** key, const uint8_t * buf, size_t buflen) | |||
| if (import_BN(&n, &buf, &buflen)) | |||
| goto err1; | |||
There was a problem hiding this comment.
Is there a reason why this is err1 while all the rest are err2?
There was a problem hiding this comment.
It's the first one, so if it failed, no memory was allocated? I'm happier to make it err2 for consistency, but I figured you'd object to that.
There was a problem hiding this comment.
No memory allocated, and no memory will be freed (I assume you've checked that). The only reason to have err1 and err2 is if you're going to continue with err3, err4, et cetera... the whole point of setting them to NULL is so that we can always jump to the same place.
There was a problem hiding this comment.
Double-checking BN_free(NULL)... the docs for 1.1 says it's fine [1], but the docs for 1.0.2 doesn't mention it [2]. However, the code for 1.0.2 [3] and even 0.9.6 [4] shows that it's ok. Should I do it manually anyway, just to be safe?
[1] https://www.openssl.org/docs/manmaster/man3/BN_free.html
[2] https://www.openssl.org/docs/man1.0.2/crypto/BN_free.html
[3] https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/crypto/bn/bn_lib.c#L247
[4] https://github.com/openssl/openssl/blob/OpenSSL_0_9_6-stable/crypto/bn/bn_lib.c#L278
|
Updated PR. If it looks good, I'll rebase the history. Question reminder: Openssl 1.1 promises that |
|
I think this is good; please clean up the commit history. |
It's rather unlikely to have a problem importing the server root, but if it happens (*cough* OpenSSL 1.1), let's be explicit about it.
This will avoid some warnings when we add OpenSSL 1.1 compatibility.
Separating the interaction between
uint8_t * buf
and
RSA ** key
is a necessary step towards OpenSSL 1.1 compatibility.
|
Rebased and ready for merging. |
No description provided.