-
Notifications
You must be signed in to change notification settings - Fork 419
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
Convert between pyOpenSSL and cryptography objects #439
Conversation
Let’s bikeshed. :) I’d be for |
as for 16.0: if it’s ready by accident, sure why not. but we’re not gonna wait for it. and please don’t stall 1.3 just to get this in :D |
OK we should start moving on this. I’m reluctant to add a 16.1 milestone to it just yet because there might be a smaller release fixing some little warts. |
ec66bcc
to
caa56a4
Compare
Current coverage is 95.03% (diff: 99.12%)@@ master #439 diff @@
==========================================
Files 7 16 +9
Lines 2067 5641 +3574
Methods 0 0
Messages 0 0
Branches 343 412 +69
==========================================
+ Hits 1869 5361 +3492
- Misses 107 198 +91
+ Partials 91 82 -9
|
51bd110
to
31573fb
Compare
Do these docs make sense? |
Oh gee, I thought we merged this at the sprints. |
Looks like I need to rebase it? |
cdffb80
to
88d05f4
Compare
I think I was waiting for a review of the docs? But I’m not sure anymore. :| |
I'm okay with the docs. In cryptography we mostly refer to our keys as instances of a type rather than interfaces, but it's not a big deal. |
I’d like to do it right so we can refer people to it that want to add bindings. The reason I've used “interfaces” is that it says “interfaces” in the docs https://cryptography.io/en/latest/hazmat/primitives/asymmetric/rsa/#key-interfaces ? Summoning @alex for more opinions. :) |
hth |
Hm I guess when we talk about types ( Last open question is the second checkbox: do we want to perform type checks? |
Is there any intention of extending this to map between PyOpenSSL's X509 object and Cryptography's? |
Yes, we just needed to start somewhere. On Tue, Jul 19, 2016 at 8:01 AM, Cory Benfield [email protected]
"I disapprove of what you say, but I will defend to the death your right to |
I would really like to land this but i’m not sure if it’s ready. It would be nice if someone could have a look and unblock us. |
|
||
.. versionadded:: 16.1.0 | ||
""" | ||
pkey = cls() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth policing this method to make sure the crypto key from cryptography isn't, say, an ECDSA key, or any other unsupported key type?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no opinion here. pyOpenSSL doesn't do much enforcement of this type, but we definitely do it in cryptography. I'll add it if you want, just let me know :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should do it: there'll be surprises if we don't.
I am mostly happy with this, though I have one question about whether we should police the type of keys we allow to be passed to the constructor. Otherwise, I am happy. =) |
@Lukasa type check added :) |
\o/ Yay! |
first shots fired 😱 |
* convert pkey to cryptography keys and vice versa * pep8 and such * Add documentation and changelog * add a type check and verify that it rejects ECDSA keys from cryptography
Add patch that makes tests on NetBSD progress further. But then there's a segfault. See pyca/pyopenssl#596 16.2.0 (2016-10-15) ------------------- Changes: ^^^^^^^^ - Fixed compatibility errors with OpenSSL 1.1.0. - Fixed an issue that caused failures with subinterpreters and embedded Pythons. `#552 <https://github.com/pyca/pyopenssl/pull/552>`_ 16.1.0 (2016-08-26) ------------------- Deprecations: ^^^^^^^^^^^^^ - Dropped support for OpenSSL 0.9.8. Changes: ^^^^^^^^ - Fix memory leak in ``OpenSSL.crypto.dump_privatekey()`` with ``FILETYPE_TEXT``. `#496 <https://github.com/pyca/pyopenssl/pull/496>`_ - Enable use of CRL (and more) in verify context. `#483 <https://github.com/pyca/pyopenssl/pull/483>`_ - ``OpenSSL.crypto.PKey`` can now be constructed from ``cryptography`` objects and also exported as such. `#439 <https://github.com/pyca/pyopenssl/pull/439>`_ - Support newer versions of ``cryptography`` which use opaque structs for OpenSSL 1.1.0 compatibility.
I'm putting this up so people can comment on this, but it is obviously incomplete:
@hynek do we want this in 16.0?