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

OpenSSL loading backend #959

Merged
merged 4 commits into from
May 22, 2014
Merged

Conversation

public
Copy link
Member

@public public commented Apr 23, 2014

No description provided.

@public public changed the title Openssl loading backend OpenSSL loading backend Apr 23, 2014
@jenkins-cryptography
Copy link

Test FAILed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1610/

@public
Copy link
Member Author

public commented Apr 23, 2014

Unscrewed my awful merge.

@jenkins-cryptography
Copy link

Test FAILed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1611/

@public
Copy link
Member Author

public commented Apr 23, 2014

Or not...

@jenkins-cryptography
Copy link

Test PASSed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1612/

@jenkins-cryptography
Copy link

Test PASSed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1613/

@jenkins-cryptography
Copy link

Test FAILed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1614/

@public
Copy link
Member Author

public commented Apr 24, 2014

More network failures :(

@reaperhulk
Copy link
Member

this can be rebased now

@public
Copy link
Member Author

public commented Apr 26, 2014

Rebased.


.. versionadded:: 0.4

Deserialize a private key from PEM encoded data to one the supported
Copy link
Member

Choose a reason for hiding this comment

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

to one of the supported

@reaperhulk reaperhulk added this to the Fourth Release milestone Apr 26, 2014
@public
Copy link
Member Author

public commented Apr 27, 2014

Updated.

@jenkins-cryptography
Copy link

Test FAILed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1664/

password was supplied.

:raises UnsupportedAlgorithm: If the serialized key is of a type that
is not supported by the backend or if the
Copy link
Member

Choose a reason for hiding this comment

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

This can be rewrapped a bit.

@reaperhulk
Copy link
Member

Other than my nit I am 👍 on this. Would like another set of eyes to ensure we're all happy with the approach though.

@jenkins-cryptography
Copy link

Test FAILed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1666/

@public
Copy link
Member Author

public commented Apr 28, 2014

I updated this last night.

@lvh
Copy link
Member

lvh commented Apr 28, 2014

I think the code here looks good, and so do the docs. Not a super huge fan of the "traditional" OpenSSL term, but I can't really come up with anything better either.

Traditional OpenSSL Format
~~~~~~~~~~~~~~~~~~~~~~~~~~

The "traditional" PKCS #1 based serialization format used by OpenSSL.
Copy link
Member

Choose a reason for hiding this comment

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

I think it would help to be more explicit in this documentation that the name "traditional" as used here is a new invention to unambiguously refer to this serialization format. As is, it reads as if there is an alternative to the traditional format that I might be interested in.

Copy link
Member Author

Choose a reason for hiding this comment

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

This isn't a new name for anything, the OpenSSL docs explicitly refer to
this as the "traditional" format quotes and all. I might be able to improve
the wording a bit though.

On 28 April 2014 20:55:50 Jean-Paul Calderone notifications@github.com wrote:

+.. hazmat::
+
+Key Serialization
+=================
+
+.. currentmodule:: cryptography.hazmat.primitives.serialization
+
+There are several common schemes for serializing asymmetric private and
public
+keys to bytes. They generally support encryption of private keys and
additional
+key metadata.
+
+
+Traditional OpenSSL Format
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The "traditional" PKCS #1 based serialization format used by OpenSSL.

I think it would help to be more explicit in this documentation that the
name "traditional" as used here is a new invention to unambiguously refer
to this serialization format. As is, it reads as if there is an
alternative to the traditional format that I might be interested in.


Reply to this email directly or view it on GitHub:
https://github.com/pyca/cryptography/pull/959/files#r12064446

@public
Copy link
Member Author

public commented May 3, 2014

Rebased for 0.4

@jenkins-cryptography
Copy link

Test PASSed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1738/

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 0d070cf on public:openssl-loading-backend into 1c851f6 on pyca:master.

@jenkins-cryptography
Copy link

Test PASSed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1742/

@public
Copy link
Member Author

public commented May 3, 2014

Now with DSA support.

@jenkins-cryptography
Copy link

Test PASSed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1743/

@coveralls
Copy link

Coverage Status

Coverage remained the same when pulling 595393d on public:openssl-loading-backend into 1c851f6 on pyca:master.

@public public modified the milestone: Fifth Release May 4, 2014
@reaperhulk
Copy link
Member

This LGTM other than our continued naming questions, but it's becoming hard to review since I've seen it so many times. Before we spend time on naming I'd like to see if others think this is ready to merge. cc @alex @dreid @Ayrx

@Ayrx
Copy link
Contributor

Ayrx commented May 6, 2014

Code LGTM.


return _MemoryBIO(self._ffi.gc(bio, self._lib.BIO_free), data_char_p)

def _evp_pkey_to_private_key(self, evp_pkey):
Copy link
Member

Choose a reason for hiding this comment

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

I would be happier if this had a docstring, if only to document the intent and return type.

@lvh
Copy link
Member

lvh commented May 16, 2014

Other than the docstring nitpicks I think this looks great and I'll be happy to merge it :) Thanks for working on this, @public !

@public
Copy link
Member Author

public commented May 16, 2014

Updated @lvh

@jenkins-cryptography
Copy link

Test FAILed.
Refer to this link for build results: https://jenkins.cryptography.io/job/cryptography-pr-experimental/1799/

@reaperhulk
Copy link
Member

Okay, if there are no objections I am going to merge this tomorrow. :) If you want to see changes or disagree with the naming you've got one day to speak up!

reaperhulk added a commit that referenced this pull request May 22, 2014
@reaperhulk reaperhulk merged commit ebf1235 into pyca:master May 22, 2014
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging this pull request may close these issues.

8 participants