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

asn1crypto uses system default libcrypto instead of cryptography's one. #4460

Closed
methane opened this issue Sep 6, 2018 · 7 comments
Closed

Comments

@methane
Copy link

methane commented Sep 6, 2018

When buidling uwsgi, Python, and cryptography, we can specify custom location of OpenSSL.
We use such option to use OpenSSL different from system's default one.

But asn1crypto loads system libcrypto for faster inverse_mod() implementation.
https://github.com/wbond/asn1crypto/blob/master/asn1crypto/_perf/_big_num_ctypes.py#L35

This may cause trouble. In our case, it caused SEGV in uwsgi application because
ABI is incompatible from libcrypto used by uwsgi.
We can avoid this SEGV by removing _perf directory in the asn1crypto. But I want
mixing incompatible OpenSSL is avoided by default.

How about embed asn1crypto without _perf module, or with custom _perf module using
cryptography's OpenSSL?
"Embedding asn1crypto without _perf" seems supported:
https://github.com/wbond/asn1crypto/blob/master/changelog.md#0182

@reaperhulk
Copy link
Member

Are you are compiling your own cryptography against your own custom OpenSSL, not the statically linked wheels we provide via PyPI? If so, are you statically or dynamically linking? What call are you making that causes the segfault?

@reaperhulk
Copy link
Member

Ah, you filed wbond/asn1crypto#113 (which is likely where any potential workaround would live anyway)

@njsmith
Copy link
Contributor

njsmith commented Sep 7, 2018

This is another casualty of unbit/uwsgi#1590, see wbond/asn1crypto#113 (comment)

@wbond
Copy link

wbond commented Sep 7, 2018

I just commented at wbond/asn1crypto#113 (comment) explaining that in all likelihood, the libcrypto dependency will be dropped since asn1crypto will likely drop the ability to compute the public key from a private key. Instead it will likely defer to a true crypto package.

@reaperhulk
Copy link
Member

Thanks for the update @wbond, we'll go ahead and close it on this side for now :)

@methane
Copy link
Author

methane commented Sep 7, 2018

Thank you!
I was not sure this issue should be fixed by which side so I filed issue on both project.
But it seems removing libcrypto dependency from asn1crypto is the simplest and
the best solution to me.

@wbond
Copy link

wbond commented Oct 9, 2019

Just for historical reference, version 1.0.0 of asn1crypto dropped the libcrypto dependency.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jul 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

4 participants