From hs at ox.cx  Mon Jan  4 08:59:37 2016
From: hs at ox.cx (Hynek Schlawack)
Date: Mon, 4 Jan 2016 14:59:37 +0100
Subject: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL
In-Reply-To: <DCA321D7-9702-4D9E-9E54-1105A1ABDC9A@ox.cx>
References: <DCA321D7-9702-4D9E-9E54-1105A1ABDC9A@ox.cx>
Message-ID: <67EF01ED-46B7-40E1-951E-F9E87BB7C06F@ox.cx>

[responding to myself because MailRoute had hiccups when Paul sent his response and I never got it.]

I?m glad I?ve met unequivocal support so far.

[Paul]:

> There's no reason why we can't do this technically. My past opposition has mostly been philosophical (if we do this we inextricably tie pyOpenSSL to cryptography), but perhaps I should just embrace it. We have everything we need to do it right now (x509 objects, RSA/EC/DSA objects), although it does require consuming some private classes/methods. Here's some untested code to show how we could do it: https://github.com/reaperhulk/pyopenssl/commit/65d0658af74c892ca261d051ed50e37519eaff98

To be honest I wasn?t aware you had any opposition. :)  I think it?s fair to assume that cryptography is here to stay and I don?t intend to break/remove the ?old ways?.

Knowing that it?s technically possible is *great news*.

> Personally, I don't have a problem with features landing in pyOpenSSL. Yes, they're frequently duplicating features in cryptography, but until cryptography is actually a full replacement I don't feel comfortable telling people to use both APIs. Once pyOpenSSL's use case vanishes outside of "legacy compatibility shim" then I would support being more aggressive about rejecting new features. Of course, reviewing/landing feature PRs is hard work and I don't have a good answer for how to deal with that. Person-hours are a precious commodity :(

Yes.  And I figure that this step would simplify a lot of things.  It would also reduce the PR ping pong between the two projects.

The nice thing is that we can add that support for each class separately.

***

[glyph]:

> In the meanwhile though, I think that from_cryptography/to_cryptography are a good idea, and should contain a clear explanation of this plan: in other words, everyone using pyOpenSSL should start rewriting their applications to use the 'cryptography' objects as much as possible.

That?s exactly my point.  It not only reduces work-load and adds features: it also starts the transition.

> Right now, things are in a bit of a muddled state; pyOpenSSL is still the only package available to do many things (in particular: TLS) but pull requests are being refused on the grounds that Cryptography has superseded it, when there still isn't a clear interop strategy.  These methods (especially if properly documented) could really improve this situation.

AFAIK, there hasn?t been a PR refused for this reason so far but there have always been awkward nudges in that direction.

***

As for planning:

I think the best way forward is to release 16.0.0 AFAIK and then start the work on this.

I will point the owners of x509-related tickets/PRs to this thread before we really start.

Opinions?

?h
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160104/56c63952/attachment.sig>

From glyph at twistedmatrix.com  Mon Jan  4 13:03:45 2016
From: glyph at twistedmatrix.com (Glyph Lefkowitz)
Date: Mon, 4 Jan 2016 10:03:45 -0800
Subject: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL
In-Reply-To: <67EF01ED-46B7-40E1-951E-F9E87BB7C06F@ox.cx>
References: <DCA321D7-9702-4D9E-9E54-1105A1ABDC9A@ox.cx>
 <67EF01ED-46B7-40E1-951E-F9E87BB7C06F@ox.cx>
Message-ID: <97DD7C44-C9A1-4782-B6D8-D21F3010A9BE@twistedmatrix.com>


> On Jan 4, 2016, at 5:59 AM, Hynek Schlawack <hs at ox.cx> wrote:
> 
> AFAIK, there hasn?t been a PR refused for this reason so far but there have always been awkward nudges in that direction.

Sorry, I probably contributed to some confusion there. I thought I saw earlier in the thread that PRs had been refused; I am not familiar with any specific ones myself.

This sounds like a good direction though, happy that you're working on it!

-g
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160104/3a764d7a/attachment.html>

From ddchen at andrew.cmu.edu  Tue Jan  5 00:11:55 2016
From: ddchen at andrew.cmu.edu (Dominic Chen)
Date: Mon, 4 Jan 2016 21:11:55 -0800
Subject: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL
Message-ID: <6EDE567C-2389-45B9-8636-92BA8235B951@andrew.cmu.edu>

To add on to the existing discussion, I agree with deprecating cryptography in favor of pyopenssl, although personally I?d prefer to see pyopenssl continue providing an updated low-level OpenSSL interface.

As a bit of background, I originally started using pyopenssl when I was writing a research tool to parse a bunch of cryptography-related file formats (e.g. PEM/DER encoded X509, PKCS12, PKCS7, etc), and dump them into a SQL database for easy searching and filtering. I settled on pyopenssl after trying a number of other Python cryptography libraries, and discovering that they lacked support for features like elliptic curve cryptography, all of PCKS7/12, etc.

But after discovering that pyopenssl was somewhat deprecated in favor of cryptography, I ended up switching to cryptography, since it appeared to better maintained, and I believe I encountered some bugs. However, I was annoyed to find out that cryptography only provided a higher-level interface, and there was a lack of feature parity between the two projects.

This was a couple of months ago, so I don?t remember the exact details, but I recall that at the time, there was limited CRL parsing support, no parsing of unsupported OID?s in certificates, and no support for PKCS7. Additionally, the checks for standards compliance were frustrating to deal with, because I was only interested in parsing and dumping a bunch of certificates, not whether they were standards compliant, or whether the library would pars known OID?s into objects. Additionally, I also encountered some more bugs as well, which I believe are now fixed.

As a result, I ended up implementing my own wrapper interface around both libraries.


Thanks,

Dominic Chen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160104/f35f98dc/attachment.sig>

From hs at ox.cx  Wed Jan  6 08:10:43 2016
From: hs at ox.cx (Hynek Schlawack)
Date: Wed, 6 Jan 2016 14:10:43 +0100
Subject: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL
In-Reply-To: <6EDE567C-2389-45B9-8636-92BA8235B951@andrew.cmu.edu>
References: <6EDE567C-2389-45B9-8636-92BA8235B951@andrew.cmu.edu>
Message-ID: <BC6E45D2-0C9D-4D19-AE84-CB0BA8962B29@ox.cx>

Hello Dominic,

> Am 05.01.2016 um 06:11 schrieb Dominic Chen <ddchen at andrew.cmu.edu>:
> 
> To add on to the existing discussion, I agree with deprecating cryptography in favor of pyopenssl, although personally I?d prefer to see pyopenssl continue providing an updated low-level OpenSSL interface.

I assume that?s a typo?  We intend to add cryptography constructors to pyOpenSSL?s x509 classes; not deprecate cryptography.

> As a bit of background, I originally started using pyopenssl when I was writing a research tool to parse a bunch of cryptography-related file formats (e.g. PEM/DER encoded X509, PKCS12, PKCS7, etc), and dump them into a SQL database for easy searching and filtering. I settled on pyopenssl after trying a number of other Python cryptography libraries, and discovering that they lacked support for features like elliptic curve cryptography, all of PCKS7/12, etc.
> 
> But after discovering that pyopenssl was somewhat deprecated in favor of cryptography, I ended up switching to cryptography, since it appeared to better maintained, and I believe I encountered some bugs. However, I was annoyed to find out that cryptography only provided a higher-level interface, and there was a lack of feature parity between the two projects.
> 
> This was a couple of months ago, so I don?t remember the exact details, but I recall that at the time, there was limited CRL parsing support, no parsing of unsupported OID?s in certificates, and no support for PKCS7. Additionally, the checks for standards compliance were frustrating to deal with, because I was only interested in parsing and dumping a bunch of certificates, not whether they were standards compliant, or whether the library would pars known OID?s into objects. Additionally, I also encountered some more bugs as well, which I believe are now fixed.
> 
> As a result, I ended up implementing my own wrapper interface around both libraries.

Thank you for your perspective for that?s what I hoped for.

Would you:

1. agree that our plans are neutral to your situation?
2. support us on making cryptography?s x509 layer more useful?  One of the key problems is that nobody maintaining pyOpenSSL actually fully understands pyOpenSSL.  Using new (but existing) APIs we understand seems like a path forward that causes least pain to everyone involved.

?

Regards,
Hynek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160106/968ac282/attachment.sig>

From d.c.ddcc at gmail.com  Wed Jan  6 12:56:28 2016
From: d.c.ddcc at gmail.com (Dominic Chen)
Date: Wed, 6 Jan 2016 09:56:28 -0800
Subject: [Cryptography-dev] Keys/Certificates/CRLs/x509 in pyOpenSSL
In-Reply-To: <BC6E45D2-0C9D-4D19-AE84-CB0BA8962B29@ox.cx>
References: <6EDE567C-2389-45B9-8636-92BA8235B951@andrew.cmu.edu>
 <BC6E45D2-0C9D-4D19-AE84-CB0BA8962B29@ox.cx>
Message-ID: <A26ED3DB-EA78-4188-949D-F93B5F244074@gmail.com>

Hynek,

You?re correct, I accidentally switched the two projects in my first sentence. I agree that the plans look fine to me, although I?m not sure how much time I?ll have to contribute at all.

Thanks,

Dominic

> On Jan 6, 2016, at 5:10 AM, Hynek Schlawack <hs at ox.cx> wrote:
> 
> Hello Dominic,
> 
>> Am 05.01.2016 um 06:11 schrieb Dominic Chen <ddchen at andrew.cmu.edu>:
>> 
>> To add on to the existing discussion, I agree with deprecating cryptography in favor of pyopenssl, although personally I?d prefer to see pyopenssl continue providing an updated low-level OpenSSL interface.
> 
> I assume that?s a typo?  We intend to add cryptography constructors to pyOpenSSL?s x509 classes; not deprecate cryptography.
> 
>> As a bit of background, I originally started using pyopenssl when I was writing a research tool to parse a bunch of cryptography-related file formats (e.g. PEM/DER encoded X509, PKCS12, PKCS7, etc), and dump them into a SQL database for easy searching and filtering. I settled on pyopenssl after trying a number of other Python cryptography libraries, and discovering that they lacked support for features like elliptic curve cryptography, all of PCKS7/12, etc.
>> 
>> But after discovering that pyopenssl was somewhat deprecated in favor of cryptography, I ended up switching to cryptography, since it appeared to better maintained, and I believe I encountered some bugs. However, I was annoyed to find out that cryptography only provided a higher-level interface, and there was a lack of feature parity between the two projects.
>> 
>> This was a couple of months ago, so I don?t remember the exact details, but I recall that at the time, there was limited CRL parsing support, no parsing of unsupported OID?s in certificates, and no support for PKCS7. Additionally, the checks for standards compliance were frustrating to deal with, because I was only interested in parsing and dumping a bunch of certificates, not whether they were standards compliant, or whether the library would pars known OID?s into objects. Additionally, I also encountered some more bugs as well, which I believe are now fixed.
>> 
>> As a result, I ended up implementing my own wrapper interface around both libraries.
> 
> Thank you for your perspective for that?s what I hoped for.
> 
> Would you:
> 
> 1. agree that our plans are neutral to your situation?
> 2. support us on making cryptography?s x509 layer more useful?  One of the key problems is that nobody maintaining pyOpenSSL actually fully understands pyOpenSSL.  Using new (but existing) APIs we understand seems like a path forward that causes least pain to everyone involved.
> 
> ?
> 
> Regards,
> Hynek
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160106/0c2de2ce/attachment.sig>

From paul.l.kehrer at gmail.com  Fri Jan  8 10:49:23 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 8 Jan 2016 07:49:23 -0800
Subject: [Cryptography-dev] PyCA/cryptography 1.2 released
Message-ID: <etPan.568fda83.6f34c1c5.1da@atlas.lan>

On behalf of all our contributors I am pleased to announce the release of PyCA/cryptography (https://github.com/pyca/cryptography) version 1.2. cryptography is a package which provides cryptographic recipes and primitives to Python developers. Our goal is for it to be your "cryptographic standard library". We support Python 2.6-2.7, Python 3.3+, and PyPy.

Changelog (https://cryptography.io/en/latest/changelog/):
?
* BACKWARDS INCOMPATIBLE: RevokedCertificate extensions now uses extension classes rather than returning raw values inside the Extension value.
* Deprecated support for OpenSSL 0.9.8 and 1.0.0. At this time there is no time table for actually dropping support, however we strongly encourage all users to upgrade as those versions no longer receive support from the OpenSSL project.
* The Certificate class now has signature and tbs_certificate_bytes attributes.
* The CertificateSigningRequest class now has signature and tbs_certrequest_bytes attributes.
* The CertificateRevocationList class now has signature and tbs_certlist_bytes attributes.
* NameConstraints are now supported in the CertificateBuilder and CertificateSigningRequestBuilder.
* Support serialization of certificate revocation lists using the public_bytes() method of CertificateRevocationList.
* Add support for parsing CertificateRevocationList extensions() in the OpenSSL backend.
* Added CertificateRevocationListBuilder and RevokedCertificateBuilder to allow creation of CRLs.
* Unrecognized non-critical X.509 extensions are now parsed into an UnrecognizedExtension object.

...and various other improvements. Please see the website changelog for documentation and additional details.

-Paul Kehrer (reaperhulk)

From paul.l.kehrer at gmail.com  Fri Jan  8 16:41:30 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 8 Jan 2016 13:41:30 -0800
Subject: [Cryptography-dev] PyCA cryptography 1.2.1 released
Message-ID: <etPan.56902d0a.4ddb0215.192@DN0a182b0c.SUNet>

If one birthday release is good, two is surely better? To test that theory PyCA cryptography 1.2.1 has been released. This version, in addition to all the changes outlined in the 1.2 release, contains a fix for an issue that caused pyOpenSSL to raise an exception in many situations (https://cryptography.io/en/latest/changelog/).

-Paul Kehrer (reaperhulk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160108/ea2a4d74/attachment.html>

From alex.gaynor at gmail.com  Tue Jan 19 22:07:01 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Tue, 19 Jan 2016 22:07:01 -0500
Subject: [Cryptography-dev] [Proposal] Intent to deprecate and remove:
 Python 2.6
In-Reply-To: <1450893161.3830.3.camel@redhat.com>
References: <CAFRnB2VDXA0dxthJnzF1hQcCqrH7EzFDACkuwXX5M-S6N9wawQ@mail.gmail.com>
 <1450893161.3830.3.camel@redhat.com>
Message-ID: <CAFRnB2WDLu_eVQo+SFH8aN8Y5wkpEEJVkExRTOU0qSQyrXw9rw@mail.gmail.com>

Hi all,

To wrap a bow on this: on reviewing data from PyPI, it looks like a
significant percentage of Paramiko users are on 2.6. There's currently an
outstanding PR to port paramiko to use cryptography, and IMO that's more
important than dropping 2.6 for overall user security, so I'm going to drop
this until such time as the data supports it, unless anyone wants to argue
in favor vigorously.

Alex

On Wed, Dec 23, 2015 at 12:52 PM, Simo Sorce <simo at redhat.com> wrote:

> On Tue, 2015-12-22 at 22:43 -0500, Alex Gaynor wrote:
> > Hi all,
> >
> > I'd like to propose we formally deprecate (in our next release) and
> remove
> > (in the release thereafter) support for Python2.6.
> >
> > It is no longer under support from its developers (which makes it a
> > security risk), its use is more or less confined to users of CentOS and
> > RHEL (which means SCL is available to them, and they have a corporate
> > benefactor to complain to if it doesn't work), and its seriously funking
> > with our development workflow because it's so abysmally slow in CI (which
> > means it's annoying me enough to want to solve this).
> >
> > There is genuinely no justifiable reason to use Python 2.6 anymore, both
> > Django and Twisted have dropped it.
> >
> > If this would _seriously_ impact you, please reply to this thread. If
> > possible I'd also like to hear from our downstreams.
>
> We do not build python-cryptography for RHEL 6 so we do not have a
> strong reason to ask for 2.6 support.
> I can't speak for potential customers that may have a different opinion
> and build it themselves.
>
> Simo.
>
> --
> Simo Sorce * Red Hat, Inc * New York
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160119/540f38a5/attachment.html>

From alex.gaynor at gmail.com  Fri Jan 22 16:58:33 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 22 Jan 2016 16:58:33 -0500
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support for
 OpenSSL 0.9.8
Message-ID: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>

Hi all,

I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next
release, and remove support in the release after (we already emit warnings
in our current release, so this is consistent with our schedule).

Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g.
no TLS 1.2), and supporting it adds complexity, in the form of hundreds of
additional lines of code and configuration options.

Supporting data: As of pip 8 (released this week, already used for
something like 1/3 of PyPI downloads), the user agent of pip includes the
system's OpenSSL version. Looking at the data (excluding Windows and OS X,
since on those platforms we include OpenSSL 1.0.2 in our wheels). The
overall distribution is:



Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all
installations.

Looking at per-package data, here are the percent of downloads using
OpenSSL 0.9.8 for some relevant packages:

- unidecode: 7.6% (This is the package with the highest percent of 0.9.8
users)
- rsa: 3.3%
- pyasn1: 2.2%
- requests: 1.6%
- pycrypto: 0.8%
- pip: 0.6%
- pyopenssl: 0.4%
- letsencrypt-apache: 0.3%
- cryptography: 0.3%


I think these numbers are low enough that we can safely drop OpenSSL 0.9.8
support.

Platforms specifically known to be affected:
- RHEL/CentOS 5 and older
- Debian Squeeze (baed on OpenSSL version, this is where most of the
affected users will be).


Thoughts? Will you be affected by this?
?Alex

-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/53eb4927/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2016-01-22 at 4.51.47 PM.png
Type: image/png
Size: 44428 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/53eb4927/attachment-0001.png>

From ronf at timeheart.net  Fri Jan 22 17:19:20 2016
From: ronf at timeheart.net (Ron Frederick)
Date: Fri, 22 Jan 2016 14:19:20 -0800
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
Message-ID: <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>

What impact will this have on MacOS systems? Even the latest MacOS El Capitan (10.11.3) is still back on OpenSSL 0.9.8zg from 14 July 2015 for the /usr/bin/openssl binary. They ship with a version of libressl for use by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that library is available for other applications or libraries to use.

On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Hi all,
> 
> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next release, and remove support in the release after (we already emit warnings in our current release, so this is consistent with our schedule).
> 
> Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g. no TLS 1.2), and supporting it adds complexity, in the form of hundreds of additional lines of code and configuration options.
> 
> Supporting data: As of pip 8 (released this week, already used for something like 1/3 of PyPI downloads), the user agent of pip includes the system's OpenSSL version. Looking at the data (excluding Windows and OS X, since on those platforms we include OpenSSL 1.0.2 in our wheels). The overall distribution is:
> 
> 
> 
> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all installations.
> 
> Looking at per-package data, here are the percent of downloads using OpenSSL 0.9.8 for some relevant packages:
> 
> - unidecode: 7.6% (This is the package with the highest percent of 0.9.8 users)
> - rsa: 3.3%
> - pyasn1: 2.2%
> - requests: 1.6%
> - pycrypto: 0.8%
> - pip: 0.6%
> - pyopenssl: 0.4%
> - letsencrypt-apache: 0.3%
> - cryptography: 0.3%
> 
> 
> I think these numbers are low enough that we can safely drop OpenSSL 0.9.8 support.
> 
> Platforms specifically known to be affected:
> - RHEL/CentOS 5 and older
> - Debian Squeeze (baed on OpenSSL version, this is where most of the affected users will be).
> 
> 
> Thoughts? Will you be affected by this?
> ?Alex
> 
> -- 
> "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
Ron Frederick
ronf at timeheart.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/dc9a0016/attachment.html>

From alex.gaynor at gmail.com  Fri Jan 22 17:21:00 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 22 Jan 2016 17:21:00 -0500
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
 <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
Message-ID: <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>

On OS X and Windows we distribute a Cryptography wheel which includes
OpenSSL 0.9.8.

Alex

On Fri, Jan 22, 2016 at 5:19 PM, Ron Frederick <ronf at timeheart.net> wrote:

> What impact will this have on MacOS systems? Even the latest MacOS El
> Capitan (10.11.3) is still back on OpenSSL 0.9.8zg from 14 July 2015 for
> the /usr/bin/openssl binary. They ship with a version of libressl for use
> by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that
> library is available for other applications or libraries to use.
>
> On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>
> Hi all,
>
> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next
> release, and remove support in the release after (we already emit warnings
> in our current release, so this is consistent with our schedule).
>
> Rationale: OpenSSL 0.9.8 is old, does not support modern web security
> (e.g. no TLS 1.2), and supporting it adds complexity, in the form of
> hundreds of additional lines of code and configuration options.
>
> Supporting data: As of pip 8 (released this week, already used for
> something like 1/3 of PyPI downloads), the user agent of pip includes the
> system's OpenSSL version. Looking at the data (excluding Windows and OS X,
> since on those platforms we include OpenSSL 1.0.2 in our wheels). The
> overall distribution is:
>
>
>
> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all
> installations.
>
> Looking at per-package data, here are the percent of downloads using
> OpenSSL 0.9.8 for some relevant packages:
>
> - unidecode: 7.6% (This is the package with the highest percent of 0.9.8
> users)
> - rsa: 3.3%
> - pyasn1: 2.2%
> - requests: 1.6%
> - pycrypto: 0.8%
> - pip: 0.6%
> - pyopenssl: 0.4%
> - letsencrypt-apache: 0.3%
> - cryptography: 0.3%
>
>
> I think these numbers are low enough that we can safely drop OpenSSL 0.9.8
> support.
>
> Platforms specifically known to be affected:
> - RHEL/CentOS 5 and older
> - Debian Squeeze (baed on OpenSSL version, this is where most of the
> affected users will be).
>
>
> Thoughts? Will you be affected by this?
> ?Alex
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
> --
> Ron Frederick
> ronf at timeheart.net
>
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/c6f0341b/attachment-0001.html>

From alex.gaynor at gmail.com  Fri Jan 22 17:21:15 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 22 Jan 2016 17:21:15 -0500
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
 <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
 <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>
Message-ID: <CAFRnB2XMt3x9mmVtbQ5VtipcJXdtcr8B0CBnNk+UhTMfs8RBEA@mail.gmail.com>

Uhhh, sorry, which includes OpenSSL *1.0.2*.

Alex

On Fri, Jan 22, 2016 at 5:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:

> On OS X and Windows we distribute a Cryptography wheel which includes
> OpenSSL 0.9.8.
>
> Alex
>
> On Fri, Jan 22, 2016 at 5:19 PM, Ron Frederick <ronf at timeheart.net> wrote:
>
>> What impact will this have on MacOS systems? Even the latest MacOS El
>> Capitan (10.11.3) is still back on OpenSSL 0.9.8zg from 14 July 2015 for
>> the /usr/bin/openssl binary. They ship with a version of libressl for use
>> by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that
>> library is available for other applications or libraries to use.
>>
>> On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>>
>> Hi all,
>>
>> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next
>> release, and remove support in the release after (we already emit warnings
>> in our current release, so this is consistent with our schedule).
>>
>> Rationale: OpenSSL 0.9.8 is old, does not support modern web security
>> (e.g. no TLS 1.2), and supporting it adds complexity, in the form of
>> hundreds of additional lines of code and configuration options.
>>
>> Supporting data: As of pip 8 (released this week, already used for
>> something like 1/3 of PyPI downloads), the user agent of pip includes the
>> system's OpenSSL version. Looking at the data (excluding Windows and OS X,
>> since on those platforms we include OpenSSL 1.0.2 in our wheels). The
>> overall distribution is:
>>
>>
>>
>> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all
>> installations.
>>
>> Looking at per-package data, here are the percent of downloads using
>> OpenSSL 0.9.8 for some relevant packages:
>>
>> - unidecode: 7.6% (This is the package with the highest percent of 0.9.8
>> users)
>> - rsa: 3.3%
>> - pyasn1: 2.2%
>> - requests: 1.6%
>> - pycrypto: 0.8%
>> - pip: 0.6%
>> - pyopenssl: 0.4%
>> - letsencrypt-apache: 0.3%
>> - cryptography: 0.3%
>>
>>
>> I think these numbers are low enough that we can safely drop OpenSSL
>> 0.9.8 support.
>>
>> Platforms specifically known to be affected:
>> - RHEL/CentOS 5 and older
>> - Debian Squeeze (baed on OpenSSL version, this is where most of the
>> affected users will be).
>>
>>
>> Thoughts? Will you be affected by this?
>> ?Alex
>>
>> --
>> "I disapprove of what you say, but I will defend to the death your right
>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>
>> --
>> Ron Frederick
>> ronf at timeheart.net
>>
>>
>>
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>>
>
>
> --
> "I disapprove of what you say, but I will defend to the death your right
> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/defe01dd/attachment.html>

From ronf at timeheart.net  Fri Jan 22 17:25:35 2016
From: ronf at timeheart.net (Ron Frederick)
Date: Fri, 22 Jan 2016 14:25:35 -0800
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <CAFRnB2XMt3x9mmVtbQ5VtipcJXdtcr8B0CBnNk+UhTMfs8RBEA@mail.gmail.com>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
 <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
 <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>
 <CAFRnB2XMt3x9mmVtbQ5VtipcJXdtcr8B0CBnNk+UhTMfs8RBEA@mail.gmail.com>
Message-ID: <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>

Gotcha, thanks.

On my OS X system, I have 1.0.2e installed from MacPorts, but I imagine many Mac users don?t.

On Jan 22, 2016, at 2:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> Uhhh, sorry, which includes OpenSSL *1.0.2*.
> 
> Alex
> 
> On Fri, Jan 22, 2016 at 5:21 PM, Alex Gaynor <alex.gaynor at gmail.com <mailto:alex.gaynor at gmail.com>> wrote:
> On OS X and Windows we distribute a Cryptography wheel which includes OpenSSL 0.9.8.
> 
> Alex
> 
> On Fri, Jan 22, 2016 at 5:19 PM, Ron Frederick <ronf at timeheart.net <mailto:ronf at timeheart.net>> wrote:
> What impact will this have on MacOS systems? Even the latest MacOS El Capitan (10.11.3) is still back on OpenSSL 0.9.8zg from 14 July 2015 for the /usr/bin/openssl binary. They ship with a version of libressl for use by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that library is available for other applications or libraries to use.
> 
> On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com <mailto:alex.gaynor at gmail.com>> wrote:
>> Hi all,
>> 
>> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next release, and remove support in the release after (we already emit warnings in our current release, so this is consistent with our schedule).
>> 
>> Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g. no TLS 1.2), and supporting it adds complexity, in the form of hundreds of additional lines of code and configuration options.
>> 
>> Supporting data: As of pip 8 (released this week, already used for something like 1/3 of PyPI downloads), the user agent of pip includes the system's OpenSSL version. Looking at the data (excluding Windows and OS X, since on those platforms we include OpenSSL 1.0.2 in our wheels). The overall distribution is:
>> 
>> 
>> 
>> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all installations.
>> 
>> Looking at per-package data, here are the percent of downloads using OpenSSL 0.9.8 for some relevant packages:
>> 
>> - unidecode: 7.6% (This is the package with the highest percent of 0.9.8 users)
>> - rsa: 3.3%
>> - pyasn1: 2.2%
>> - requests: 1.6%
>> - pycrypto: 0.8%
>> - pip: 0.6%
>> - pyopenssl: 0.4%
>> - letsencrypt-apache: 0.3%
>> - cryptography: 0.3%
>> 
>> 
>> I think these numbers are low enough that we can safely drop OpenSSL 0.9.8 support.
>> 
>> Platforms specifically known to be affected:
>> - RHEL/CentOS 5 and older
>> - Debian Squeeze (baed on OpenSSL version, this is where most of the affected users will be).
>> 
>> 
>> Thoughts? Will you be affected by this?
>> ?Alex
>> 
>> -- 
>> "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>> "The people's good is the highest law." -- Cicero
>> GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
Ron Frederick
ronf at timeheart.net



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/47c4620e/attachment-0001.html>

From paul.l.kehrer at gmail.com  Fri Jan 22 17:27:07 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 22 Jan 2016 16:27:07 -0600
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
 <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
 <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>
 <CAFRnB2XMt3x9mmVtbQ5VtipcJXdtcr8B0CBnNk+UhTMfs8RBEA@mail.gmail.com>
 <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>
Message-ID: <etPan.56a2acbb.49a4c1f0.312@atlas.local>

We assume nobody has it installed, which is why the wheel statically links it. It, unfortunately, shifts the upgrade burden to "remember to upgrade your python package", but there's no way around that.

On January 22, 2016 at 4:25:46 PM, Ron Frederick (ronf at timeheart.net) wrote:

Gotcha, thanks.

On my OS X system, I have 1.0.2e installed from MacPorts, but I imagine many Mac users don?t.

On Jan 22, 2016, at 2:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
Uhhh, sorry, which includes OpenSSL *1.0.2*.

Alex

On Fri, Jan 22, 2016 at 5:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
On OS X and Windows we distribute a Cryptography wheel which includes OpenSSL 0.9.8.

Alex

On Fri, Jan 22, 2016 at 5:19 PM, Ron Frederick <ronf at timeheart.net> wrote:
What impact will this have on MacOS systems? Even the latest MacOS El Capitan (10.11.3) is still back on?OpenSSL 0.9.8zg from 14 July 2015 for the /usr/bin/openssl binary. They ship with a version of libressl for use by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that library is available for other applications or libraries to use.

On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
Hi all,

I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next release, and remove support in the release after (we already emit warnings in our current release, so this is consistent with our schedule).

Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g. no TLS 1.2), and supporting it adds complexity, in the form of hundreds of additional lines of code and configuration options.

Supporting data: As of pip 8 (released this week, already used for something like 1/3 of PyPI downloads), the user agent of pip includes the system's OpenSSL version. Looking at the data (excluding Windows and OS X, since on those platforms we include OpenSSL 1.0.2 in our wheels). The overall distribution is:



Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all installations.

Looking at per-package data, here are the percent of downloads using OpenSSL 0.9.8 for some relevant packages:

- unidecode:?7.6% (This is the package with the highest percent of 0.9.8 users)
- rsa: 3.3%
-?pyasn1: 2.2%
- requests: 1.6%
- pycrypto: 0.8%
- pip: 0.6%
-?pyopenssl: 0.4%
-?letsencrypt-apache: 0.3%
-?cryptography: 0.3%


I think these numbers are low enough that we can safely drop OpenSSL 0.9.8 support.

Platforms specifically known to be affected:
- RHEL/CentOS 5 and older
- Debian Squeeze (baed on OpenSSL version, this is where most of the affected users will be).


Thoughts? Will you be affected by this?
?Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint:?125F 5C67 DFE9 4084
--?
Ron Frederick
ronf at timeheart.net



_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/fc03d286/attachment.html>

From paul.l.kehrer at gmail.com  Fri Jan 22 17:29:13 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 22 Jan 2016 16:29:13 -0600
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
 <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
 <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>
 <CAFRnB2XMt3x9mmVtbQ5VtipcJXdtcr8B0CBnNk+UhTMfs8RBEA@mail.gmail.com>
 <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>
 <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>
Message-ID: <etPan.56a2ad3a.2ee8692e.312@atlas.local>

We should also disable 1.0.0 as that's EOL as well and has even lower usage than 0.9.8. I'd like to have at least one additional release with 0.9.8/1.0.0 support disabled but available via env variable (e.g. ALLOW_OLD_BAD_OPENSSL). This way we can provide a path to re-enable support if it turns out more people are using cryptography with old Python than our data currently suggests.

-Paul Kehrer (reaperhulk)
On January 22, 2016 at 4:25:46 PM, Ron Frederick (ronf at timeheart.net) wrote:

Gotcha, thanks.

On my OS X system, I have 1.0.2e installed from MacPorts, but I imagine many Mac users don?t.

On Jan 22, 2016, at 2:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
Uhhh, sorry, which includes OpenSSL *1.0.2*.

Alex

On Fri, Jan 22, 2016 at 5:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
On OS X and Windows we distribute a Cryptography wheel which includes OpenSSL 0.9.8.

Alex

On Fri, Jan 22, 2016 at 5:19 PM, Ron Frederick <ronf at timeheart.net> wrote:
What impact will this have on MacOS systems? Even the latest MacOS El Capitan (10.11.3) is still back on?OpenSSL 0.9.8zg from 14 July 2015 for the /usr/bin/openssl binary. They ship with a version of libressl for use by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that library is available for other applications or libraries to use.

On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
Hi all,

I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next release, and remove support in the release after (we already emit warnings in our current release, so this is consistent with our schedule).

Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g. no TLS 1.2), and supporting it adds complexity, in the form of hundreds of additional lines of code and configuration options.

Supporting data: As of pip 8 (released this week, already used for something like 1/3 of PyPI downloads), the user agent of pip includes the system's OpenSSL version. Looking at the data (excluding Windows and OS X, since on those platforms we include OpenSSL 1.0.2 in our wheels). The overall distribution is:



Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all installations.

Looking at per-package data, here are the percent of downloads using OpenSSL 0.9.8 for some relevant packages:

- unidecode:?7.6% (This is the package with the highest percent of 0.9.8 users)
- rsa: 3.3%
-?pyasn1: 2.2%
- requests: 1.6%
- pycrypto: 0.8%
- pip: 0.6%
-?pyopenssl: 0.4%
-?letsencrypt-apache: 0.3%
-?cryptography: 0.3%


I think these numbers are low enough that we can safely drop OpenSSL 0.9.8 support.

Platforms specifically known to be affected:
- RHEL/CentOS 5 and older
- Debian Squeeze (baed on OpenSSL version, this is where most of the affected users will be).


Thoughts? Will you be affected by this?
?Alex

--
"I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint:?125F 5C67 DFE9 4084
--?
Ron Frederick
ronf at timeheart.net



_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/a275cf6a/attachment-0001.html>

From alex.gaynor at gmail.com  Fri Jan 22 17:33:19 2016
From: alex.gaynor at gmail.com (Alex Gaynor)
Date: Fri, 22 Jan 2016 17:33:19 -0500
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <etPan.56a2ad3a.2ee8692e.312@atlas.local>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
 <40852AF8-B352-4BEF-9A7C-B5F168B9B384@timeheart.net>
 <CAFRnB2WQLjbnsefrz=dhNV3MyBGf1tKGhDuYAJ_YuPriT2v=Fg@mail.gmail.com>
 <CAFRnB2XMt3x9mmVtbQ5VtipcJXdtcr8B0CBnNk+UhTMfs8RBEA@mail.gmail.com>
 <93D0B16C-C3FD-44DE-85E4-A60CF27FAFE9@timeheart.net>
 <etPan.56a2ad3a.2ee8692e.312@atlas.local>
Message-ID: <CAFRnB2VRjNCETy2X-8e1kKDB9iEwKAZNFxwy7gAzs_wHkZHBCA@mail.gmail.com>

So, here was my thought process on 1.0.0:
- Basically no one is using it
- It's slightly less burdensome to support.
- We should only do one thing at a time, if for some reason everyone who
upgrades 0.9.8 moves to 1.0.0, that's an interesting data point we should
seek to collect.

I like the idea of adding a CRYPTOGRAPHY_ALLOW_DEPRECATED_OPENSSL for 1
release. That makes the timetable
- 1.3: Show deprecation warning
- 1.4: Removed by default with CRYPTOGRAPHY_ALLOW_DEPRECATED_OPENSSL
fallback
- 1.5: Removed entirely

With the 1.5 step contigent on feedback we receive from 1.4.

Alex

On Fri, Jan 22, 2016 at 5:29 PM, Paul Kehrer <paul.l.kehrer at gmail.com>
wrote:

> We should also disable 1.0.0 as that's EOL as well and has even lower
> usage than 0.9.8. I'd like to have at least one additional release with
> 0.9.8/1.0.0 support disabled but available via env variable (e.g.
> ALLOW_OLD_BAD_OPENSSL). This way we can provide a path to re-enable support
> if it turns out more people are using cryptography with old Python than our
> data currently suggests.
>
> -Paul Kehrer (reaperhulk)
>
> On January 22, 2016 at 4:25:46 PM, Ron Frederick (ronf at timeheart.net)
> wrote:
>
> Gotcha, thanks.
>
> On my OS X system, I have 1.0.2e installed from MacPorts, but I imagine
> many Mac users don?t.
>
> On Jan 22, 2016, at 2:21 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>
> Uhhh, sorry, which includes OpenSSL *1.0.2*.
>
> Alex
>
> On Fri, Jan 22, 2016 at 5:21 PM, Alex Gaynor <alex.gaynor at gmail.com>
> wrote:
>
>> On OS X and Windows we distribute a Cryptography wheel which includes
>> OpenSSL 0.9.8.
>>
>> Alex
>>
>> On Fri, Jan 22, 2016 at 5:19 PM, Ron Frederick <ronf at timeheart.net>
>> wrote:
>>
>>> What impact will this have on MacOS systems? Even the latest MacOS El
>>> Capitan (10.11.3) is still back on OpenSSL 0.9.8zg from 14 July 2015 for
>>> the /usr/bin/openssl binary. They ship with a version of libressl for use
>>> by OpenSSH (OpenSSH_6.9p1, LibreSSL 2.1.8), but I don?t know if that
>>> library is available for other applications or libraries to use.
>>>
>>> On Jan 22, 2016, at 1:58 PM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next
>>> release, and remove support in the release after (we already emit warnings
>>> in our current release, so this is consistent with our schedule).
>>>
>>> Rationale: OpenSSL 0.9.8 is old, does not support modern web security
>>> (e.g. no TLS 1.2), and supporting it adds complexity, in the form of
>>> hundreds of additional lines of code and configuration options.
>>>
>>> Supporting data: As of pip 8 (released this week, already used for
>>> something like 1/3 of PyPI downloads), the user agent of pip includes the
>>> system's OpenSSL version. Looking at the data (excluding Windows and OS X,
>>> since on those platforms we include OpenSSL 1.0.2 in our wheels). The
>>> overall distribution is:
>>>
>>>
>>>
>>> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all
>>> installations.
>>>
>>> Looking at per-package data, here are the percent of downloads using
>>> OpenSSL 0.9.8 for some relevant packages:
>>>
>>> - unidecode: 7.6% (This is the package with the highest percent of
>>> 0.9.8 users)
>>> - rsa: 3.3%
>>> - pyasn1: 2.2%
>>> - requests: 1.6%
>>> - pycrypto: 0.8%
>>> - pip: 0.6%
>>> - pyopenssl: 0.4%
>>> - letsencrypt-apache: 0.3%
>>> - cryptography: 0.3%
>>>
>>>
>>> I think these numbers are low enough that we can safely drop OpenSSL
>>> 0.9.8 support.
>>>
>>> Platforms specifically known to be affected:
>>> - RHEL/CentOS 5 and older
>>> - Debian Squeeze (baed on OpenSSL version, this is where most of the
>>> affected users will be).
>>>
>>>
>>> Thoughts? Will you be affected by this?
>>> ?Alex
>>>
>>> --
>>> "I disapprove of what you say, but I will defend to the death your right
>>> to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
>>> "The people's good is the highest law." -- Cicero
>>> GPG Key fingerprint: 125F 5C67 DFE9 4084
>>>
>>> --
> Ron Frederick
> ronf at timeheart.net
>
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>


-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160122/6ca2682b/attachment.html>

From cory at lukasa.co.uk  Mon Jan 25 07:27:56 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Mon, 25 Jan 2016 12:27:56 +0000
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
Message-ID: <F0DC8064-EC29-42C6-8456-ED466241471F@lukasa.co.uk>

I am strongly in favour of dropping 0.9.8 support. Count me as an enthusiastic +1.

Cory

> On 22 Jan 2016, at 21:58, Alex Gaynor <alex.gaynor at gmail.com> wrote:
> 
> Hi all,
> 
> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next release, and remove support in the release after (we already emit warnings in our current release, so this is consistent with our schedule).
> 
> Rationale: OpenSSL 0.9.8 is old, does not support modern web security (e.g. no TLS 1.2), and supporting it adds complexity, in the form of hundreds of additional lines of code and configuration options.
> 
> Supporting data: As of pip 8 (released this week, already used for something like 1/3 of PyPI downloads), the user agent of pip includes the system's OpenSSL version. Looking at the data (excluding Windows and OS X, since on those platforms we include OpenSSL 1.0.2 in our wheels). The overall distribution is:
> 
> <Screen Shot 2016-01-22 at 4.51.47 PM.png>
> 
> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all installations.
> 
> Looking at per-package data, here are the percent of downloads using OpenSSL 0.9.8 for some relevant packages:
> 
> - unidecode: 7.6% (This is the package with the highest percent of 0.9.8 users)
> - rsa: 3.3%
> - pyasn1: 2.2%
> - requests: 1.6%
> - pycrypto: 0.8%
> - pip: 0.6%
> - pyopenssl: 0.4%
> - letsencrypt-apache: 0.3%
> - cryptography: 0.3%
> 
> 
> I think these numbers are low enough that we can safely drop OpenSSL 0.9.8 support.
> 
> Platforms specifically known to be affected:
> - RHEL/CentOS 5 and older
> - Debian Squeeze (baed on OpenSSL version, this is where most of the affected users will be).
> 
> 
> Thoughts? Will you be affected by this?
> ?Alex
> 
> --
> "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160125/866bbf4d/attachment.sig>

From bestark at cisco.com  Tue Jan 26 11:29:10 2016
From: bestark at cisco.com (Benton Stark (bestark))
Date: Tue, 26 Jan 2016 16:29:10 +0000
Subject: [Cryptography-dev] Python HSM Module
Message-ID: <4deeccba622749ac98cc618bf68d2834@XCH-RCD-006.cisco.com>

Hello everyone,



I have a HSM (Hardware Security Module) Python library that supports direct access to HSMs.  I developed the library and companion C code for internal use at my company specially for use with SafeNet HSMs but the library can work with any PKCS#11 API compliant HSM.  I am going through our internal procedures to get the code open sourced.  One of the requirements before I can do that is collect information on a need or interest in such a library to the Python community.  I am not sure if this mailer is the right place and if not maybe someone can direct me elsewhere.  I can provide more information if this is indeed the best place to discuss it.



Thanks,



Benton Stark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/5567a61b/attachment.html>

From paul.l.kehrer at gmail.com  Tue Jan 26 11:40:31 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Tue, 26 Jan 2016 10:40:31 -0600
Subject: [Cryptography-dev] Python HSM Module
In-Reply-To: <4deeccba622749ac98cc618bf68d2834@XCH-RCD-006.cisco.com>
References: <4deeccba622749ac98cc618bf68d2834@XCH-RCD-006.cisco.com>
Message-ID: <etPan.56a7a17f.76b5e6f9.312@atlas.local>

Hi Benton,

This mailing list is meant for discussion of the development of PyCA/cryptography (https://github.com/pyca/cryptography) and also other projects under the Python Cryptographic Authority (https://github.com/pyca).

Our interest primarily lies with implementing PKCS11 using cryptography's backend interfaces (https://cryptography.io/en/latest/hazmat/backends/interfaces/) and not in a separate library. That said, a well-written PKCS11 interface would likely be useful to people who aren't comfortable with the C FFI options in Python.

-Paul Kehrer (reaperhulk)

On January 26, 2016 at 10:30:27 AM, Benton Stark (bestark) (bestark at cisco.com) wrote:

Hello everyone,

?

I have a HSM (Hardware Security Module) Python library that supports direct access to HSMs.? I developed the library and companion C code for internal use at my company specially for use with SafeNet HSMs but the library can work with any PKCS#11 API compliant HSM.? I am going through our internal procedures to get the code open sourced.? One of the requirements before I can do that is collect information on a need or interest in such a library to the Python community.? I am not sure if this mailer is the right place and if not maybe someone can direct me elsewhere.? I can provide more information if this is indeed the best place to discuss it.

?

Thanks,

?

Benton Stark

_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/1cb3970b/attachment.html>

From stanislaw.pitucha at hpe.com  Tue Jan 26 12:07:51 2016
From: stanislaw.pitucha at hpe.com (Pitucha, Stanislaw Izaak)
Date: Tue, 26 Jan 2016 17:07:51 +0000
Subject: [Cryptography-dev] Python HSM Module
In-Reply-To: <4deeccba622749ac98cc618bf68d2834@XCH-RCD-006.cisco.com>
References: <4deeccba622749ac98cc618bf68d2834@XCH-RCD-006.cisco.com>
Message-ID: <F2CEBDD2D596EC45A4D5479F72C865C504E635BF@G1W3786.americas.hpqcorp.net>

I?m very much interested in a simple HSM interface for Anchor project (ephemeral certs CA). Feel free to reach out if you?d like more info.

 

Best Regards,

Stanis?aw Pitucha

 

From: Cryptography-dev [mailto:cryptography-dev-bounces+stanislaw.pitucha=hp.com at python.org] On Behalf Of Benton Stark (bestark)
Sent: Wednesday, January 27, 2016 3:29 AM
To: cryptography-dev at python.org
Subject: [Cryptography-dev] Python HSM Module

 

Hello everyone,

 

I have a HSM (Hardware Security Module) Python library that supports direct access to HSMs.  I developed the library and companion C code for internal use at my company specially for use with SafeNet HSMs but the library can work with any PKCS#11 API compliant HSM.  I am going through our internal procedures to get the code open sourced.  One of the requirements before I can do that is collect information on a need or interest in such a library to the Python community.  I am not sure if this mailer is the right place and if not maybe someone can direct me elsewhere.  I can provide more information if this is indeed the best place to discuss it.

 

Thanks,

 

Benton Stark

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/5c3c4093/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/5c3c4093/attachment.bin>

From misaki.miyashita at oracle.com  Tue Jan 26 11:05:04 2016
From: misaki.miyashita at oracle.com (Misaki Miyashita)
Date: Tue, 26 Jan 2016 10:05:04 -0600
Subject: [Cryptography-dev] [Proposal] Deprecating and removing support
 for OpenSSL 0.9.8
In-Reply-To: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
References: <CAFRnB2V1ccejzeOct=+S5CwTOdCOGsguUdaHeLt8803-OZZR+Q@mail.gmail.com>
Message-ID: <56A79930.4060306@oracle.com>

Oracle Solaris is fine with dropping 0.9.8 support as well.

Thank you.

Regards,

Misaki Miyashita
------------------------------------------
Oracle Solaris
Principal Software Engineer

On 1/22/2016 3:58 PM, Alex Gaynor wrote:
> Hi all,
>
> I'd like to propose we deprecate support for OpenSSL 0.9.8 in our next 
> release, and remove support in the release after (we already emit 
> warnings in our current release, so this is consistent with our schedule).
>
> Rationale: OpenSSL 0.9.8 is old, does not support modern web security 
> (e.g. no TLS 1.2), and supporting it adds complexity, in the form of 
> hundreds of additional lines of code and configuration options.
>
> Supporting data: As of pip 8 (released this week, already used for 
> something like 1/3 of PyPI downloads), the user agent of pip includes 
> the system's OpenSSL version. Looking at the data (excluding Windows 
> and OS X, since on those platforms we include OpenSSL 1.0.2 in our 
> wheels). The overall distribution is:
>
>
>
> Indicating that OpenSSL 0.9.8 on Linux repersents less than 1% of all 
> installations.
>
> Looking at per-package data, here are the percent of downloads using 
> OpenSSL 0.9.8 for some relevant packages:
>
> - unidecode: 7.6% (This is the package with the highest percent of 
> 0.9.8 users)
> - rsa: 3.3%
> - pyasn1: 2.2%
> - requests: 1.6%
> - pycrypto: 0.8%
> - pip: 0.6%
> - pyopenssl: 0.4%
> - letsencrypt-apache: 0.3%
> - cryptography: 0.3%
>
>
> I think these numbers are low enough that we can safely drop OpenSSL 
> 0.9.8 support.
>
> Platforms specifically known to be affected:
> - RHEL/CentOS 5 and older
> - Debian Squeeze (baed on OpenSSL version, this is where most of the 
> affected users will be).
>
>
> Thoughts? Will you be affected by this?
> ?Alex
>
> -- 
> "I disapprove of what you say, but I will defend to the death your 
> right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
> "The people's good is the highest law." -- Cicero
> GPG Key fingerprint: 125F 5C67 DFE9 4084
>
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/d9d87c84/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/png
Size: 44428 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/d9d87c84/attachment-0001.png>

From jianhua at us.ibm.com  Tue Jan 26 12:26:15 2016
From: jianhua at us.ibm.com (Jeff Feng)
Date: Tue, 26 Jan 2016 11:26:15 -0600
Subject: [Cryptography-dev] Python HSM Module
In-Reply-To: <F2CEBDD2D596EC45A4D5479F72C865C504E635BF@G1W3786.americas.hpqcorp.net>
References: <4deeccba622749ac98cc618bf68d2834@XCH-RCD-006.cisco.com>
 <F2CEBDD2D596EC45A4D5479F72C865C504E635BF@G1W3786.americas.hpqcorp.net>
Message-ID: <201601261726.u0QHQKrb022974@d01av02.pok.ibm.com>

Hi Benton,

This is a pkcs11 wrapper https://pypi.python.org/pypi/pykcs11
Yours maybe different from it. Just FYI.


Regards
Jeff  Feng
IBM Cloud,  OpenStack Infrastructure Services
(512)286-9426, T/L  363-9426



From:	"Pitucha, Stanislaw Izaak" <stanislaw.pitucha at hpe.com>
To:	"cryptography-dev at python.org" <cryptography-dev at python.org>
Date:	01/26/2016 11:16 AM
Subject:	Re: [Cryptography-dev] Python HSM Module
Sent by:	"Cryptography-dev" <cryptography-dev-bounces
            +jianhua=us.ibm.com at python.org>



I?m very much interested in a simple HSM interface for Anchor project
(ephemeral certs CA). Feel free to reach out if you?d like more info.

Best Regards,
Stanis?aw Pitucha

From: Cryptography-dev [mailto:cryptography-dev-bounces
+stanislaw.pitucha=hp.com at python.org] On Behalf Of Benton Stark (bestark)
Sent: Wednesday, January 27, 2016 3:29 AM
To: cryptography-dev at python.org
Subject: [Cryptography-dev] Python HSM Module

Hello everyone,

I have a HSM (Hardware Security Module) Python library that supports direct
access to HSMs.  I developed the library and companion C code for internal
use at my company specially for use with SafeNet HSMs but the library can
work with any PKCS#11 API compliant HSM.  I am going through our internal
procedures to get the code open sourced.  One of the requirements before I
can do that is collect information on a need or interest in such a library
to the Python community.  I am not sure if this mailer is the right place
and if not maybe someone can direct me elsewhere.  I can provide more
information if this is indeed the best place to discuss it.

Thanks,

Benton Stark[attachment "smime.p7s" deleted by Jeff Feng/Austin/IBM]
_______________________________________________
Cryptography-dev mailing list
Cryptography-dev at python.org
https://mail.python.org/mailman/listinfo/cryptography-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/e5339e4d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/e5339e4d/attachment.gif>

From kevgliss at gmail.com  Tue Jan 26 17:04:59 2016
From: kevgliss at gmail.com (Kevin Glisson)
Date: Tue, 26 Jan 2016 22:04:59 +0000
Subject: [Cryptography-dev] Python HSM Module
In-Reply-To: <mailman.330.1453829751.2337.cryptography-dev@python.org>
References: <mailman.330.1453829751.2337.cryptography-dev@python.org>
Message-ID: <CABKcAf=q8gBTTXTM9cHta+0QL6NMD+00RGrgw174wrZAXpDdKQ@mail.gmail.com>

I would also be interested in such a library.

Cheers,
Kevin

On Tue, Jan 26, 2016 at 9:35 AM <cryptography-dev-request at python.org> wrote:

>
> Date: Tue, 26 Jan 2016 17:07:51 +0000
> From: "Pitucha, Stanislaw Izaak" <stanislaw.pitucha at hpe.com>
> To: "cryptography-dev at python.org" <cryptography-dev at python.org>
> Subject: Re: [Cryptography-dev] Python HSM Module
> Message-ID:
>         <
> F2CEBDD2D596EC45A4D5479F72C865C504E635BF at G1W3786.americas.hpqcorp.net>
>
> Content-Type: text/plain; charset="utf-8"
>
> I?m very much interested in a simple HSM interface for Anchor project
> (ephemeral certs CA). Feel free to reach out if you?d like more info.
>
>
>
> Best Regards,
>
> Stanis?aw Pitucha
>
>
>
> From: Cryptography-dev [mailto:cryptography-dev-bounces+stanislaw.pitucha=
> hp.com at python.org] On Behalf Of Benton Stark (bestark)
> Sent: Wednesday, January 27, 2016 3:29 AM
> To: cryptography-dev at python.org
> Subject: [Cryptography-dev] Python HSM Module
>
>
>
> Hello everyone,
>
>
>
> I have a HSM (Hardware Security Module) Python library that supports
> direct access to HSMs.  I developed the library and companion C code for
> internal use at my company specially for use with SafeNet HSMs but the
> library can work with any PKCS#11 API compliant HSM.  I am going through
> our internal procedures to get the code open sourced.  One of the
> requirements before I can do that is collect information on a need or
> interest in such a library to the Python community.  I am not sure if this
> mailer is the right place and if not maybe someone can direct me
> elsewhere.  I can provide more information if this is indeed the best place
> to discuss it.
>
>
>
> Thanks,
>
>
>
> Benton Stark
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/5c3c4093/attachment-0001.html
> >
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 5801 bytes
> Desc: not available
> URL: <
> http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/5c3c4093/attachment-0001.bin
> >
>
> ------------------------------
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/111f1368/attachment.html>

From mc5686 at mclink.it  Tue Jan 26 21:55:49 2016
From: mc5686 at mclink.it (Mauro Condarelli)
Date: Wed, 27 Jan 2016 03:55:49 +0100
Subject: [Cryptography-dev] Buildroot support
Message-ID: <56A831B5.2020608@mclink.it>

Hi,
I am trying to port cryptography to a Buildroot-based ARM system.

Unfortunately basic cross-compilation fails with the message below.
Since I am not a Python programmer and I just need Cryptography as a prerequisite for autobahn I am unable to understand what went wrong.

It seems to me compilation is trying to use on Host (x86_64) a shared lib (/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so) meant to run on Target (ARM).

Can someone help, please?

Thanks in Advance
Mauro

(cd /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1//; PATH="/home/mcon/emotiq/new/Buildroot/output/host/bin:/home/mcon/emotiq/new/Buildroot/output/host/sbin:/home/mcon/emotiq/new/Buildroot/output/host/usr/bin:/home/mcon/emotiq/new/Buildroot/output/host/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" CC="/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O3 " LDFLAGS="" LDSHARED="/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc -shared" PYTHONPATH="/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/sysconfigdata/:/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/" _python_sysroot=/home/mcon/emotiq/new/Buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot _python_prefix=/usr _python_exec_prefix=/usr 
/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/python setup.py build --executable=/usr/bin/python )

Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/cffi-1.5.0-py2.7-linux-x86_64.egg
Searching for pycparser
Reading https://pypi.python.org/simple/pycparser/
Best match: pycparser 2.14
Downloading https://pypi.python.org/packages/source/p/pycparser/pycparser-2.14.tar.gz#md5=a2bc8d28c923b4fe2b2c3b4b51a4f935
Processing pycparser-2.14.tar.gz
Writing /tmp/easy_install-OMTOyu/pycparser-2.14/setup.cfg
Running pycparser-2.14/setup.py -q bdist_egg --dist-dir /tmp/easy_install-OMTOyu/pycparser-2.14/egg-dist-tmp-Oz3sRX
warning: no previously-included files matching 'yacctab.*' found under directory 'tests'
warning: no previously-included files matching 'lextab.*' found under directory 'tests'
warning: no previously-included files matching 'yacctab.*' found under directory 'examples'
warning: no previously-included files matching 'lextab.*' found under directory 'examples'
zip_safe flag not set; analyzing archive contents...
Moving pycparser-2.14-py2.7.egg to /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs

Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/pycparser-2.14-py2.7.egg
Traceback (most recent call last):
   File "setup.py", line 318, in <module>
     **keywords_with_side_effects(sys.argv)
   File "/home/mcon/emotiq/new/Buildroot/output/host/usr/lib/python2.7/distutils/core.py", line 111, in setup
     _setup_distribution = dist = klass(attrs)
   File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 272, in __init__
   File "/home/mcon/emotiq/new/Buildroot/output/host/usr/lib/python2.7/distutils/dist.py", line 287, in __init__
     self.finalize_options()
   File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 327, in finalize_options
   File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 161, in cffi_modules
     add_cffi_module(dist, cffi_module)
   File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 48, in add_cffi_module
     execfile(build_file_name, mod_vars)
   File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 24, in execfile
     exec(code, glob, glob)
   File "src/_cffi_src/build_openssl.py", line 98, in <module>
     extra_link_args=extra_link_args(compiler_type()),
   File "src/_cffi_src/utils.py", line 64, in build_ffi_for_binding
     extra_link_args=extra_link_args,
   File "src/_cffi_src/utils.py", line 72, in build_ffi
     ffi = FFI()
   File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/api.py", line 56, in __init__
     import _cffi_backend as backend
ImportError: /home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so: wrong ELF class: ELFCLASS32
package/pkg-generic.mk:195: recipe for target '/home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.stamp_built' failed
make[1]: *** [/home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.stamp_built] Error 1



From paul.l.kehrer at gmail.com  Tue Jan 26 22:19:26 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Tue, 26 Jan 2016 21:19:26 -0600
Subject: [Cryptography-dev] Buildroot support
In-Reply-To: <56A831B5.2020608@mclink.it>
References: <56A831B5.2020608@mclink.it>
Message-ID: <etPan.56a8373e.1f8aae51.312@atlas.local>

This error:?

ImportError: /home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so: wrong ELF class: ELFCLASS32?

suggests that the issue is with how cffi was compiled and not with cryptography. Looking further back in the output I see it says:

Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/cffi-1.5.0-py2.7-linux-x86_64.egg?

Did you accidentally copy an x86-64 compiled egg over to the system?

-Paul Kehrer (reaperhulk)
On January 26, 2016 at 9:12:01 PM, Mauro Condarelli (mc5686 at mclink.it) wrote:

Hi,  
I am trying to port cryptography to a Buildroot-based ARM system.  

Unfortunately basic cross-compilation fails with the message below.  
Since I am not a Python programmer and I just need Cryptography as a prerequisite for autobahn I am unable to understand what went wrong.  

It seems to me compilation is trying to use on Host (x86_64) a shared lib (/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so) meant to run on Target (ARM).  

Can someone help, please?  

Thanks in Advance  
Mauro  

(cd /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1//; PATH="/home/mcon/emotiq/new/Buildroot/output/host/bin:/home/mcon/emotiq/new/Buildroot/output/host/sbin:/home/mcon/emotiq/new/Buildroot/output/host/usr/bin:/home/mcon/emotiq/new/Buildroot/output/host/usr/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" CC="/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O3 " LDFLAGS="" LDSHARED="/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabi-gcc -shared" PYTHONPATH="/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/sysconfigdata/:/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/" _python_sysroot=/home/mcon/emotiq/new/Buildroot/output/host/usr/arm-buildroot-linux-gnueabi/sysroot _python_prefix=/usr _python_exec_prefix=/usr  
/home/mcon/emotiq/new/Buildroot/output/host/usr/bin/python setup.py build --executable=/usr/bin/python )  

Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/cffi-1.5.0-py2.7-linux-x86_64.egg  
Searching for pycparser  
Reading https://pypi.python.org/simple/pycparser/  
Best match: pycparser 2.14  
Downloading https://pypi.python.org/packages/source/p/pycparser/pycparser-2.14.tar.gz#md5=a2bc8d28c923b4fe2b2c3b4b51a4f935  
Processing pycparser-2.14.tar.gz  
Writing /tmp/easy_install-OMTOyu/pycparser-2.14/setup.cfg  
Running pycparser-2.14/setup.py -q bdist_egg --dist-dir /tmp/easy_install-OMTOyu/pycparser-2.14/egg-dist-tmp-Oz3sRX  
warning: no previously-included files matching 'yacctab.*' found under directory 'tests'  
warning: no previously-included files matching 'lextab.*' found under directory 'tests'  
warning: no previously-included files matching 'yacctab.*' found under directory 'examples'  
warning: no previously-included files matching 'lextab.*' found under directory 'examples'  
zip_safe flag not set; analyzing archive contents...  
Moving pycparser-2.14-py2.7.egg to /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs  

Installed /home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.eggs/pycparser-2.14-py2.7.egg  
Traceback (most recent call last):  
File "setup.py", line 318, in <module>  
**keywords_with_side_effects(sys.argv)  
File "/home/mcon/emotiq/new/Buildroot/output/host/usr/lib/python2.7/distutils/core.py", line 111, in setup  
_setup_distribution = dist = klass(attrs)  
File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 272, in __init__  
File "/home/mcon/emotiq/new/Buildroot/output/host/usr/lib/python2.7/distutils/dist.py", line 287, in __init__  
self.finalize_options()  
File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 327, in finalize_options  
File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 161, in cffi_modules  
add_cffi_module(dist, cffi_module)  
File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 48, in add_cffi_module  
execfile(build_file_name, mod_vars)  
File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/setuptools_ext.py", line 24, in execfile  
exec(code, glob, glob)  
File "src/_cffi_src/build_openssl.py", line 98, in <module>  
extra_link_args=extra_link_args(compiler_type()),  
File "src/_cffi_src/utils.py", line 64, in build_ffi_for_binding  
extra_link_args=extra_link_args,  
File "src/_cffi_src/utils.py", line 72, in build_ffi  
ffi = FFI()  
File "/home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/cffi/api.py", line 56, in __init__  
import _cffi_backend as backend  
ImportError: /home/mcon/emotiq/new/Buildroot/output/target/usr/lib/python2.7/site-packages/_cffi_backend.so: wrong ELF class: ELFCLASS32  
package/pkg-generic.mk:195: recipe for target '/home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.stamp_built' failed  
make[1]: *** [/home/mcon/emotiq/new/Buildroot/output/build/python-cryptography-1.2.1/.stamp_built] Error 1  


_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160126/6bd8b86a/attachment.html>

From matt.s.b.42 at gmail.com  Wed Jan 27 20:31:02 2016
From: matt.s.b.42 at gmail.com (Matt Bullock)
Date: Thu, 28 Jan 2016 01:31:02 +0000
Subject: [Cryptography-dev] accessing elliptic curve domain parameters
 (a/b/p/etc)
Message-ID: <CAKaOsVzp=+-dW-v78j9AjYKMJhOMQpPZgsnjU8fNahu87-w+6A@mail.gmail.com>

For a project I am working on, I have a need to encode/decode elliptic
curve points using point compression[1].  As this is not yet supported
natively by the cryptography library, I have started implementing it myself
but have hit a snag.  Unlike the uncompressed point encoding, in order to
decode a compressed curve point I need to be able to reference the curve
parameters.  I have been searching through the cryptography documentation
and code but cannot find any way of retrieving these values from the
backend.

Is there a method for this that I am missing, or is this functionality not
yet available?

thanks
   --Matt

[1] 2.3.3/2.3.4 http://www.secg.org/sec1-v2.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160128/051f1956/attachment.html>

From paul.l.kehrer at gmail.com  Wed Jan 27 20:39:14 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Wed, 27 Jan 2016 19:39:14 -0600
Subject: [Cryptography-dev] accessing elliptic curve domain parameters
 (a/b/p/etc)
In-Reply-To: <CAKaOsVzp=+-dW-v78j9AjYKMJhOMQpPZgsnjU8fNahu87-w+6A@mail.gmail.com>
References: <CAKaOsVzp=+-dW-v78j9AjYKMJhOMQpPZgsnjU8fNahu87-w+6A@mail.gmail.com>
Message-ID: <etPan.56a97142.3066f9.ae36@atlas.local>

Hi Matt,

There are multiple issue/pull requests for this but unfortunately GitHub is down at the moment so I can't look them up... Once GitHub is back up and running take a look at?https://github.com/pyca/cryptography/pull/2476?(that PR might have been split into other PRs that we've been discussing, but hopefully we've cross linked them)

Please weigh in on that as knowing all the potential consumers helps us decide whether the increase in API surface area is worthwhile.

-Paul Kehrer (reaperhulk)
On January 27, 2016 at 7:34:28 PM, Matt Bullock (matt.s.b.42 at gmail.com) wrote:

For a project I am working on, I have a need to encode/decode elliptic curve points using point compression[1].? As this is not yet supported natively by the cryptography library, I have started implementing it myself but have hit a snag.? Unlike the uncompressed point encoding, in order to decode a compressed curve point I need to be able to reference the curve parameters.? I have been searching through the cryptography documentation and code but cannot find any way of retrieving these values from the backend.

Is there a method for this that I am missing, or is this functionality not yet available?

thanks
? ?--Matt

[1] 2.3.3/2.3.4?http://www.secg.org/sec1-v2.pdf

_______________________________________________  
Cryptography-dev mailing list  
Cryptography-dev at python.org  
https://mail.python.org/mailman/listinfo/cryptography-dev  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160127/387b675a/attachment.html>

From matt.s.b.42 at gmail.com  Wed Jan 27 20:44:25 2016
From: matt.s.b.42 at gmail.com (Matt Bullock)
Date: Thu, 28 Jan 2016 01:44:25 +0000
Subject: [Cryptography-dev] accessing elliptic curve domain parameters
 (a/b/p/etc)
In-Reply-To: <etPan.56a97142.3066f9.ae36@atlas.local>
References: <CAKaOsVzp=+-dW-v78j9AjYKMJhOMQpPZgsnjU8fNahu87-w+6A@mail.gmail.com>
 <etPan.56a97142.3066f9.ae36@atlas.local>
Message-ID: <CAKaOsVzR3UhgkxduHvPKrkFEk0AJ=8RQHmWHFspwc0XmUiOFnQ@mail.gmail.com>

Nice, thanks, I'll take a look at that once GitHub is back up.

   --Matt

On Wed, Jan 27, 2016 at 8:39 PM Paul Kehrer <paul.l.kehrer at gmail.com> wrote:

> Hi Matt,
>
> There are multiple issue/pull requests for this but unfortunately GitHub
> is down at the moment so I can't look them up... Once GitHub is back up and
> running take a look at https://github.com/pyca/cryptography/pull/2476 (that
> PR might have been split into other PRs that we've been discussing, but
> hopefully we've cross linked them)
>
> Please weigh in on that as knowing all the potential consumers helps us
> decide whether the increase in API surface area is worthwhile.
>
> -Paul Kehrer (reaperhulk)
>
> On January 27, 2016 at 7:34:28 PM, Matt Bullock (matt.s.b.42 at gmail.com)
> wrote:
>
> For a project I am working on, I have a need to encode/decode elliptic
> curve points using point compression[1].  As this is not yet supported
> natively by the cryptography library, I have started implementing it myself
> but have hit a snag.  Unlike the uncompressed point encoding, in order to
> decode a compressed curve point I need to be able to reference the curve
> parameters.  I have been searching through the cryptography documentation
> and code but cannot find any way of retrieving these values from the
> backend.
>
> Is there a method for this that I am missing, or is this functionality not
> yet available?
>
> thanks
>    --Matt
>
> [1] 2.3.3/2.3.4 http://www.secg.org/sec1-v2.pdf
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
> _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160128/27a67b22/attachment.html>

From matt.s.b.42 at gmail.com  Wed Jan 27 23:18:18 2016
From: matt.s.b.42 at gmail.com (Matt Bullock)
Date: Thu, 28 Jan 2016 04:18:18 +0000
Subject: [Cryptography-dev] accessing elliptic curve domain parameters
 (a/b/p/etc)
In-Reply-To: <CAKaOsVzR3UhgkxduHvPKrkFEk0AJ=8RQHmWHFspwc0XmUiOFnQ@mail.gmail.com>
References: <CAKaOsVzp=+-dW-v78j9AjYKMJhOMQpPZgsnjU8fNahu87-w+6A@mail.gmail.com>
 <etPan.56a97142.3066f9.ae36@atlas.local>
 <CAKaOsVzR3UhgkxduHvPKrkFEk0AJ=8RQHmWHFspwc0XmUiOFnQ@mail.gmail.com>
Message-ID: <CAKaOsVyX9Ev4E4OC+VAGCk4pVevt25VhKZKWJWh=-LRNvYwuPg@mail.gmail.com>

Yup, that looks like that would cover exposing the values I need.  I was
originally thinking pulling them from the backend, but I guess this way
it's independent of the backend implementation (and it's not like the
values will change).  I'll keep an eye on those pull requests and plan that
part of my code to adopt them once they're in a release.

thanks
   --Matt

On Wed, Jan 27, 2016 at 8:44 PM Matt Bullock <matt.s.b.42 at gmail.com> wrote:

> Nice, thanks, I'll take a look at that once GitHub is back up.
>
>    --Matt
>
> On Wed, Jan 27, 2016 at 8:39 PM Paul Kehrer <paul.l.kehrer at gmail.com>
> wrote:
>
>> Hi Matt,
>>
>> There are multiple issue/pull requests for this but unfortunately GitHub
>> is down at the moment so I can't look them up... Once GitHub is back up and
>> running take a look at https://github.com/pyca/cryptography/pull/2476 (that
>> PR might have been split into other PRs that we've been discussing, but
>> hopefully we've cross linked them)
>>
>> Please weigh in on that as knowing all the potential consumers helps us
>> decide whether the increase in API surface area is worthwhile.
>>
>> -Paul Kehrer (reaperhulk)
>>
>> On January 27, 2016 at 7:34:28 PM, Matt Bullock (matt.s.b.42 at gmail.com)
>> wrote:
>>
>> For a project I am working on, I have a need to encode/decode elliptic
>> curve points using point compression[1].  As this is not yet supported
>> natively by the cryptography library, I have started implementing it myself
>> but have hit a snag.  Unlike the uncompressed point encoding, in order to
>> decode a compressed curve point I need to be able to reference the curve
>> parameters.  I have been searching through the cryptography documentation
>> and code but cannot find any way of retrieving these values from the
>> backend.
>>
>> Is there a method for this that I am missing, or is this functionality
>> not yet available?
>>
>> thanks
>>    --Matt
>>
>> [1] 2.3.3/2.3.4 http://www.secg.org/sec1-v2.pdf
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org
>> https://mail.python.org/mailman/listinfo/cryptography-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160128/53694e1e/attachment-0001.html>

From paul.l.kehrer at gmail.com  Fri Jan 29 14:35:46 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 29 Jan 2016 13:35:46 -0600
Subject: [Cryptography-dev] PyCA/cryptography 1.2.2 released
Message-ID: <etPan.56abbf12.1cec572.ae36@atlas.local>

PyCA/cryptography 1.2.2 has been released to PyPI. This version updates the windows and OS X wheels to be compiled against 1.0.2f and contains no other changes.

-Paul Kehrer (reaperhulk)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160129/984e3565/attachment.html>