Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix OpenSSL v1.1 compatibility #153

Merged
merged 1 commit into from
Aug 8, 2017
Merged

Fix OpenSSL v1.1 compatibility #153

merged 1 commit into from
Aug 8, 2017

Conversation

hrobeers
Copy link

@hrobeers hrobeers commented Aug 3, 2017

Runs and tests pass using openssl 1.1.0.f on Archlinux
Also tested for backwards compatibility with openssl 1.0

Please test if it compiles and runs on your system, heavy testing will be done on the second fork client.

@sunnyking
Copy link
Member

Is this code change from Bitcoin, if so is it possible to reference a bitcoin change here? Also, is there impact to build requirements?

@hrobeers
Copy link
Author

hrobeers commented Aug 4, 2017

@sunnyking
Bitcoin removed the OpenSSL depenency in v0.12. Therefore they did not have to upgrade to OpenSSL v1.1.
We figured that fixing the compatibility with OpenSSL v1.1 is much lower risk than doing another rebase to v0.12 under time pressure.

The fix should be very straightforward to review for anyone familiar with OpenSSL. In the mean time I tested it to fully validate both the mainnet & testnet chain.

@saeveritt
Copy link
Member

Compiled on Debian 9.1 and running with OpenSSL 1.1.0f on testnet.

src/key.cpp Outdated
if (sig->r) BN_clear_free(sig->r);
if (sig->s) BN_clear_free(sig->s);
sig->r = sig_r;
sig->s = sig_s;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This changes the behavior a bit. I don't know the internals of openssl, but if it ever keeps another reference to r and s then this code breaks it. It's most likely not the case, but keeping the old code as it was would be simpler and less risky.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wanted to avoid duplication of the BN_bin2bn function calls.
But I agree keeping the old code here might be safer. Will change.

@sigmike
Copy link
Member

sigmike commented Aug 5, 2017

The code looks good to me, except for all the new *_new function calls where allocation failure is not handled.

@hrobeers
Copy link
Author

hrobeers commented Aug 5, 2017

Thanks, @sigmike great feedback.
I forgot about the allocation failures indeed, will fix!

How did you think to handle a possible allocation failure in the Bignum ctor?
Throwing std::bad_alloc ?

@sigmike
Copy link
Member

sigmike commented Aug 6, 2017

Yes.

@hrobeers
Copy link
Author

hrobeers commented Aug 7, 2017

I decided to reuse the bignum_error exception for consistency.

@hrobeers
Copy link
Author

hrobeers commented Aug 7, 2017

Ok this should be it guys.

Rewrote history squashed everything in one commit for clarity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants