Mailman 3 April 2015 - Cryptography-dev

Need advice on how to get started contributing to pyca/cryptography
by Eeshan Garg May 2, 2015

May 2, 2015

Hello! I really want to contribute to pyca/cryptography. I already have a development environment setup and I have run the tests. At the PyCon sprints I worked on <https://github.com/pyca/cryptography/issues/1440>, and I also submitted a PR for it <https://github.com/pyca/cryptography/pull/1841>, but it was decided that we won't be moving forward with what I was working on. It would mean a lot to me if someone could give me some guidance and help me find something to work on and get started. :-) Thanks, Eeshan Garg

2 5

Concern over x509 interface design
by Erik Trauschke April 30, 2015

April 30, 2015

Hi all, First of all I'd like to express how happy I am about this unified approach to crypto mechanisms in Python and how active this project is. I'm currently in the process of migrating a project from M2Crypto to cryptography which will require a few additional things which are not in the code yet but which I plan to add (and contribute to the project). I'm a bit concerned about the interface decisions for things like the Certificate() class in that it doesn't seem to lead in a direction that I will easily be able to instantiate Certifcate objects in the future. I'd think that it should be possible to do this: c = x509.Certificate() c.issuer = issuer_object or c.set_issuer(issuer_object) ... At the moment I don't see how the current architecture will allow that in the future. Even if I instantiate a _Certificate object from the backend (which I shouldn't have to) I would still have to pass an x509 object (talking about the OpenSSL backend here) to the constructor. I don't say that this is wrong but it should be at least a keyword argument. Since you are laying the ground work for an interface which probably shouldn't be changed all the time, it seems dangerous to have required arguments which are complicated for an user to pass. With a keyword argument you can have it work right now without writing additional code but in the future the object might be instantiated much easier without changing the interface incompatibly. But even then there is still the problem that the x509.Certificate class can not be instantiated by itself. I guess one could have a make_cert() function in x509.py which creates a proper cert for the user based on the selected backend. Or maybe another class which inherits from Certificate but I don't know how one would be able to associate it with the right backend. I know what you are trying to do with the abstract base classes, I'm just wondering if that creates an interface which is complicated to consume. I haven't found any information about what the final goal for the interface design is so maybe the current state is just the groundwork and you already have a plan in mind on how this all is supposed to be used once it's done. So please don't see this as criticism and more as a general question. Thanks Erik

2 4

ecdsa key x/y coordinates
by Olivier Sallou April 21, 2015

April 21, 2015

Hi, I load an ecdsa private key in my program: secret = load_pem_private_key(content_file.read().encode('utf-8'), password=None, backend=default_backend()) That's fine.... I need now to get the x and y coordinates of my ecdsa key to share it with an other program. Is there any way to get it ? I do not find in API the way to do so. Thanks Olivier -- gpg key id: 4096R/326D8438 (keyring.debian.org) Key fingerprint = 5FB4 6F83 D3B9 5204 6335 D26D 78DC 68DB 326D 8438

2 1

pyca/cryptography python 3.2 support
by Paul Kehrer April 18, 2015

April 18, 2015

Recently we've had several situations where our project's Python 3.2 support blocks us from using libraries we'd like to consume (idna, characteristic, etc). Donald opened an issue (https://github.com/pyca/cryptography/issues/1809) with some evidence that we're performing significant contortions to support a version no one uses. I propose that we drop support for Python 3.2 in the next release and move forward with Python 2.6 (deprecated but no timeline for removal), Python 2.7, and 3.3+ support. I've put in a PR (https://github.com/pyca/cryptography/pull/1846) to note this in the changelog and update our travis configuration. If there are no substantial objections in the next few days we can merge and then update jenkins to reflect this as well. -Paul Kehrer

7 10

[ANN] pyOpenSSL 0.15
by Hynek Schlawack April 16, 2015

April 16, 2015

Greetings fellow Pythoneers, I'm happy to announce that pyOpenSSL 0.15 is now available. pyOpenSSL is a set of Python bindings for OpenSSL. It includes some low-level cryptography APIs but is primarily focused on providing an API for using the TLS protocol from Python. Check out the PyPI page (<https://pypi.python.org/pypi/pyOpenSSL>) for downloads. *** This is the last release under the stewardship of Jean-Paul Calderone and the maintainership is now taken over by the Python Cryptography Authority (PyCA) which has been developing the C-bindings for pyOpenSSL for a while (aka cryptography). We’d like to thank him for his great work over the past years and hope to be able to keep moving the project into a direction that will make him only slightly sad. *** The highlights of this release include: - Support to ECDHE, - NPN and ALPN support, - …many bug fixes! It’s worth pointing out that OpenSSL functions generally work on *byte strings* because they mirror OpenSSL APIs and OpenSSL is not Unicode-aware. Passing Unicode strings tends to accidentally work due do implicit decodes on Python 2 but they emit a DeprecationWarning now. Please note that DeprecationWarnings are silenced by default on Python 2.7. See the ChangeLog at <https://github.com/pyca/pyopenssl/blob/0.15/ChangeLog> for more details! On behalf of PyCA, Hynek Schlawack

4 4

PyCA cryptography 0.8.2 release
by Paul Kehrer April 11, 2015

April 11, 2015

PyCA cryptography 0.8.2 has been released to PyPI. Changelog: * Fixed a race condition when initializing the OpenSSL or CommonCrypto backends in a multi-threaded scenario. -Paul Kehrer (reaperhulk)

1 0