From paul.l.kehrer at gmail.com  Tue Mar  1 21:19:41 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Tue, 1 Mar 2016 20:19:41 -0600
Subject: [Cryptography-dev] PyCA cryptography 1.2.3 released
Message-ID: <etPan.56d64dbd.13192feb.c603@atlas.local>

PyCA cryptography 1.2.3 has been released to PyPI. This version updates the Windows and OS X wheels to be compiled with OpenSSL 1.0.2g.

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

From hs at ox.cx  Wed Mar 16 08:04:50 2016
From: hs at ox.cx (Hynek Schlawack)
Date: Wed, 16 Mar 2016 13:04:50 +0100
Subject: [Cryptography-dev] Upcoming pyOpenSSL release
Message-ID: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>

Hi,

after a (too) long time, we?re zeroing in to a new pyOpenSSL release.  Currently we?re mostly waiting for cryptography 1.3 to drop and to understand this very scary test failure: https://github.com/pyca/pyopenssl/issues/447

***

At that occasion, I would like to raise a few questions and explanations:

# The version number will now follow CalVer.

It?s known that I don?t like SemVer, however this case is a bit more subtle.  pyOpenSSL is old and mature. Therefore a 0.x version is ludicrous.  However going 1.0 doesn?t make any sense because there will never be a 2.0.  We will keep it alive as long as possible, but there will be no compatibility breaking changes to be expected.  I still believe in cryptography.tls.

# The communities need to coalesce.

This is both an announcement and a question.  I refuse to take care of the #pyopenssl channel and the pyopenssl-users mailing list.  They have to be merged into PyCa.

Now the question is: should I just send everyone to cryptography-dev and #cryptography-dev or are we going forth and finally do a #pyca/#pyca-dev channels and/or mailing lists?

# Domain?

We spoke a few times about it without a real conclusion.  I find having a pyca.io like pypa.io would be neato.

# CoC

The PSF CoC is crap.  Anyone opposed adopting http://contributor-covenant.org which seems to be the general consensus outside ?my constitutional rights are violated if I can?t go full Torvalds in code review? circles?

Best,
?h

From sigmavirus24 at gmail.com  Wed Mar 16 09:42:44 2016
From: sigmavirus24 at gmail.com (Ian Cordasco)
Date: Wed, 16 Mar 2016 08:42:44 -0500
Subject: [Cryptography-dev] Upcoming pyOpenSSL release
In-Reply-To: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
References: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
Message-ID: <CAORZOQYwV9T9sqzmovqHsPOwzGKtBNRKNLNSEb9z4Tpp9GXYHA@mail.gmail.com>

On Mar 16, 2016 7:04 AM, "Hynek Schlawack" <hs at ox.cx> wrote:
>
> Hi,
>
> after a (too) long time, we?re zeroing in to a new pyOpenSSL release.
Currently we?re mostly waiting for cryptography 1.3 to drop and to
understand this very scary test failure:
https://github.com/pyca/pyopenssl/issues/447
>
> ***
>
> At that occasion, I would like to raise a few questions and explanations:
>
> # The version number will now follow CalVer.
>
> It?s known that I don?t like SemVer, however this case is a bit more
subtle.  pyOpenSSL is old and mature. Therefore a 0.x version is
ludicrous.  However going 1.0 doesn?t make any sense because there will
never be a 2.0.  We will keep it alive as long as possible, but there will
be no compatibility breaking changes to be expected.  I still believe in
cryptography.tls.

For pyOpenSSL, this makes sense. +1

> # The communities need to coalesce.
>
> This is both an announcement and a question.  I refuse to take care of
the #pyopenssl channel and the pyopenssl-users mailing list.  They have to
be merged into PyCa.
>
> Now the question is: should I just send everyone to cryptography-dev and
#cryptography-dev or are we going forth and finally do a #pyca/#pyca-dev
channels and/or mailing lists?

The PyCQA is making due with exactly one channel for now. I would say that
it depends on how much activity you expect to be in the combined channels.

> # Domain?
>
> We spoke a few times about it without a real conclusion.  I find having a
pyca.io like pypa.io would be neato.

Could also do something like '.org' like the PyCQA.

> # CoC
>
> The PSF CoC is crap.  Anyone opposed adopting
http://contributor-covenant.org which seems to be the general consensus
outside ?my constitutional rights are violated if I can?t go full Torvalds
in code review? circles?

We adopted the contributor covenant in the PyCQA so consider me in favor of
the PyCA adopting it even though I'm not a member.

Cheers,
Ian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160316/6e120f6f/attachment.html>

From cory at lukasa.co.uk  Wed Mar 16 11:34:21 2016
From: cory at lukasa.co.uk (Cory Benfield)
Date: Wed, 16 Mar 2016 15:34:21 +0000
Subject: [Cryptography-dev] Upcoming pyOpenSSL release
In-Reply-To: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
References: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
Message-ID: <E0691682-58B4-4DCD-87C5-1986BAB09C77@lukasa.co.uk>

Speaking with my committer hat on?


> On 16 Mar 2016, at 12:04, Hynek Schlawack <hs at ox.cx> wrote:
> 
> # The communities need to coalesce.
> 
> This is both an announcement and a question.  I refuse to take care of the #pyopenssl channel and the pyopenssl-users mailing list.  They have to be merged into PyCa.
> 
> Now the question is: should I just send everyone to cryptography-dev and #cryptography-dev or are we going forth and finally do a #pyca/#pyca-dev channels and/or mailing lists?

I literally didn?t know that the list/channel existed. I?ve used #cryptography-dev for both purposes. I?d be ok with bringing it into /#?cryptography-dev/.

> # Domain?
> 
> We spoke a few times about it without a real conclusion.  I find having a pyca.io like pypa.io would be neat.

Sure.

> # CoC
> 
> The PSF CoC is crap.  Anyone opposed adopting http://contributor-covenant.org which seems to be the general consensus outside ?my constitutional rights are violated if I can?t go full Torvalds in code review? circles?

I?m strongly +1 on adopting the contributor covenant, which I already use everywhere else I can.

Cory
-------------- 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/20160316/048dc90d/attachment.sig>

From paul.l.kehrer at gmail.com  Wed Mar 16 20:22:24 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Wed, 16 Mar 2016 20:22:24 -0400
Subject: [Cryptography-dev] Upcoming pyOpenSSL release
In-Reply-To: <E0691682-58B4-4DCD-87C5-1986BAB09C77@lukasa.co.uk>
References: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
 <E0691682-58B4-4DCD-87C5-1986BAB09C77@lukasa.co.uk>
Message-ID: <etPan.56e9f8c0.5e9ae402.375@atlas.local>

On March 16, 2016 at 11:34:32 AM, Cory Benfield (cory at lukasa.co.uk) wrote:
Speaking with my committer hat on??


> On 16 Mar 2016, at 12:04, Hynek Schlawack <hs at ox.cx> wrote:?
>?
> # The communities need to coalesce.?
>?
> This is both an announcement and a question. I refuse to take care of the #pyopenssl channel and the pyopenssl-users mailing list. They have to be merged into PyCa.?
>?
> Now the question is: should I just send everyone to cryptography-dev and #cryptography-dev or are we going forth and finally do a #pyca/#pyca-dev channels and/or mailing lists??
I don't really have an objection to #pyca/#pyca-dev. Assuming Alex is also okay with it would you be willing to do the freenode juju for setting up a channel redirect from #cryptography-dev and getting things like botbot.me?configured? Is it possible to rename this mailing list?



I literally didn?t know that the list/channel existed. I?ve used #cryptography-dev for both purposes. I?d be ok with bringing it into /#?cryptography-dev/.?

> # Domain??
>?
> We spoke a few times about it without a real conclusion. I find having a pyca.io like pypa.io would be neat.?

Sure.?
What do you envision as a landing page? We don't really have any content to live on a site like that right now right?



> # CoC?
>?
> The PSF CoC is crap. Anyone opposed adopting http://contributor-covenant.org which seems to be the general consensus outside ?my constitutional rights are violated if I can?t go full Torvalds in code review? circles??

I?m strongly +1 on adopting the contributor covenant, which I already use everywhere else I can.?
We've talked a bit in the past about a CoC for cryptography since there's a general consensus that the PSF CoC isn't particularly useful. This issue (https://github.com/pyca/cryptography/issues/2161) discussed Open Code of Conduct, but hynek mentioned contributor convenant at the time and it seems like it has gained some mindshare. I have no objection to it being adopted for pyopenssl and potentially cryptography as well.



Cory?
_______________________________________________?
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/20160316/e8870250/attachment.html>

From donald at stufft.io  Thu Mar 17 06:12:52 2016
From: donald at stufft.io (Donald Stufft)
Date: Thu, 17 Mar 2016 06:12:52 -0400
Subject: [Cryptography-dev] Upcoming pyOpenSSL release
In-Reply-To: <etPan.56e9f8c0.5e9ae402.375@atlas.local>
References: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
 <E0691682-58B4-4DCD-87C5-1986BAB09C77@lukasa.co.uk>
 <etPan.56e9f8c0.5e9ae402.375@atlas.local>
Message-ID: <1486EE45-5664-44DC-87DC-6DA1657474B8@stufft.io>


> On Mar 16, 2016, at 8:22 PM, Paul Kehrer <paul.l.kehrer at gmail.com> wrote:
> 
> What do you envision as a landing page? We don't really have any content to live on a site like that right now right?

For pypa.io we just have some high level ?here?s what the PyPA is, here?s our communication stuff, here?s some goals and history? kind of stuff. Not sure if that?d be useful for PyCA though.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160317/ae4e5552/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160317/ae4e5552/attachment.sig>

From hs at ox.cx  Thu Mar 17 08:07:42 2016
From: hs at ox.cx (Hynek Schlawack)
Date: Thu, 17 Mar 2016 13:07:42 +0100
Subject: [Cryptography-dev] Upcoming pyOpenSSL release
In-Reply-To: <etPan.56e9f8c0.5e9ae402.375@atlas.local>
References: <2716FC59-0E16-4133-BCEB-E3820CD88E0B@ox.cx>
 <E0691682-58B4-4DCD-87C5-1986BAB09C77@lukasa.co.uk>
 <etPan.56e9f8c0.5e9ae402.375@atlas.local>
Message-ID: <80E79483-7231-4C27-BBAD-F3D2FCC4C51C@ox.cx>

> I don't really have an objection to #pyca/#pyca-dev. Assuming Alex is also okay with it would you be willing to do the freenode juju for setting up a channel redirect from #cryptography-dev and getting things like botbot.me <http://botbot.me/> configured? Is it possible to rename this mailing list?
> 
I?d say just (#)pyca would be enough.  If it ever gets too busy, we can always open additional channels.

>> > # Domain? 
>> > 
>> > We spoke a few times about it without a real conclusion. I find having a pyca.io <http://pyca.io/> like pypa.io <http://pypa.io/> would be neat. 
>> 
>> Sure. 
> 
> What do you envision as a landing page? We don't really have any content to live on a site like that right now right?
> 

What Donald wrote.  Some general info, a few words about the currently supported projects (we don?t really have an overview what projects we have and why ATM) maybe GPG keys.

>> > # CoC 
>> > 
>> > The PSF CoC is crap. Anyone opposed adopting http://contributor-covenant.org <http://contributor-covenant.org/> which seems to be the general consensus outside ?my constitutional rights are violated if I can?t go full Torvalds in code review? circles? 
>> 
>> I?m strongly +1 on adopting the contributor covenant, which I already use everywhere else I can. 
> 
> We've talked a bit in the past about a CoC for cryptography since there's a general consensus that the PSF CoC isn't particularly useful. This issue (https://github.com/pyca/cryptography/issues/2161 <https://github.com/pyca/cryptography/issues/2161>) discussed Open Code of Conduct, but hynek mentioned contributor convenant at the time and it seems like it has gained some mindshare. I have no objection to it being adopted for pyopenssl and potentially cryptography as well.
> 

Since nobody objected, I?m doing this for pyOpenSSL for now.  Since cryptography is mostly yours and Alex?s, I don?t want to impose any meta burden on you.

Cheers,
?h
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20160317/1b755ef7/attachment-0001.html>

From paul.l.kehrer at gmail.com  Fri Mar 18 09:26:38 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Fri, 18 Mar 2016 09:26:38 -0400
Subject: [Cryptography-dev] PyCA/cryptography 1.3 released
Message-ID: <etPan.56ec020e.2d9dd781.375@atlas.local>

On behalf of all our contributors I am pleased to announce the release of PyCA/cryptography (https://github.com/pyca/cryptography) version 1.3. 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/): 

* Added support for padding ANSI X.923 with ANSIX923.
* Deprecated support for OpenSSL 0.9.8. Support will be removed in cryptography 1.4.
* Added support for the PolicyConstraints X.509 extension including both parsing and generation using CertificateBuilder and CertificateSigningRequestBuilder.
* Added is_signature_valid to CertificateSigningRequest.
* Fixed an intermittent AssertionError when performing an RSA decryption on an invalid ciphertext, ValueError is now correctly raised in all cases.
* Added from_issuer_subject_key_identifier().


...and the typical miscellaneous improvements. Please see the website changelog for documentation and additional details. 

-Paul Kehrer (reaperhulk)

From hs at ox.cx  Sat Mar 19 07:29:28 2016
From: hs at ox.cx (Hynek Schlawack)
Date: Sat, 19 Mar 2016 12:29:28 +0100
Subject: [Cryptography-dev] pyOpenSSL 16.0.0 released
Message-ID: <F3921E30-C365-4134-9396-E44470578222@ox.cx>

On behalf of PyCA ? the Python Cryptography Authority ? I?m anxious to announce that after almost a year since the 0.15.1 release of pyOpenSSL we?ve released the brand new 16.0.0.

A few organizational notes:

1. The pyopenssl-users mailing list and #pyopenssl IRC channel are deprecated.  Please use cryptography-dev <https://mail.python.org/pipermail/cryptography-dev/> and #cryptography-dev on Freenode where you?re much more likely to get help.
2. The version scheme switched to CalVer because a 0.x version for a 15 years old project is rather odd and calling it 1.0 although we don?t expect a 2.0 to ever happen didn?t make any sense.  pyOpenSSL is a long-running project with strict backward-compatibility requirements and is hence better served with a calendar-based version scheme.
3. Please note that some of us will be doing a TLS/HTTPS workshop at PyCon US 2016 so if you always wanted to learn about these things first hand, make sure to sign up: <https://us.pycon.org/2016/schedule/presentation/1786/>.  We've opted to receive no compensation and asked the organizers to send them to PyLadies instead.  So you?ll be doing good while learning something!

***

Release details:

While the list of changes looks short, a lot internal work happened:

72 files changed, 15511 insertions(+), 15063 deletions(-)

We?ve done our best to not break any existing applications; including by making the urllib3 and Twisted test suites part of our CI.

The full changelog can be found at <https://pyopenssl.readthedocs.org/en/stable/changelog.html>.

This is the first release under full stewardship of PyCA. We have made many changes to make local development more pleasing. The test suite now passes both on Linux and OS X with OpenSSL 0.9.8, 1.0.1, and 1.0.2. It has been moved to py.test, all CI test runs are part of tox and the source code has been made fully flake8 compliant.

We hope to have lowered the barrier for contributions significantly but are open to hear about any remaining frustrations.


Backward-incompatible changes:

? Python 3.2 support has been dropped. It never had significant real world usage and has been dropped by our main dependency cryptography. Affected users should upgrade to Python 3.3 or later.


Deprecations:

? The support for EGD has been removed. The only affected function OpenSSL.rand.egd() now uses os.urandom() to seed the internal PRNG instead. Please see pyca/cryptography#1636 for more background information on this decision. In accordance with our backward compatibility policy OpenSSL.rand.egd() will be removed no sooner than a year from the release of 16.0.0.
Please note that you should use urandom for all your secure random number needs.
	? Python 2.6 support has been deprecated. Our main dependency cryptography deprecated 2.6 in version 0.9 (2015-05-14) with no time table for actually dropping it. pyOpenSSL will drop Python 2.6 support once cryptography does.


Changes:

? Fixed OpenSSL.SSL.Context.set_session_id, OpenSSL.SSL.Connection.renegotiate, OpenSSL.SSL.Connection.renegotiate_pending, and OpenSSL.SSL.Context.load_client_ca. They were lacking an implementation since 0.14. #422
? Fixed segmentation fault when using keys larger than 4096-bit to sign data. #428
? Fixed AttributeError when OpenSSL.SSL.Connection.get_app_data() was called before setting any app data. #304
? Added OpenSSL.crypto.dump_publickey() to dump OpenSSL.crypto.PKey objects that represent public keys, and OpenSSL.crypto.load_publickey() to load such objects from serialized representations. #382
? Added OpenSSL.crypto.dump_crl() to dump a certificate revocation list out to a string buffer. #368
? Added OpenSSL.SSL.Connection.get_state_string() using the OpenSSL binding state_string_long. #358
? Added support for the socket.MSG_PEEK flag to OpenSSL.SSL.Connection.recv() and OpenSSL.SSL.Connection.recv_into(). #294
? Added OpenSSL.SSL.Connection.get_protocol_version() and OpenSSL.SSL.Connection.get_protocol_version_name(). #244
? Switched to utf8string mask by default. OpenSSL formerly defaulted to a T61String if there were UTF-8 characters present. This was changed to default to UTF8String in the config around 2005, but the actual code didn't change it until late last year. This will default us to the setting that actually works. To revert this you can call OpenSSL.crypto._lib.ASN1_STRING_set_default_mask_asc(b"default"). #234

***

For PyCA,
Hynek Schlawack
-------------- 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/20160319/a343510d/attachment.sig>

From matt.s.b.42 at gmail.com  Sun Mar 20 11:53:40 2016
From: matt.s.b.42 at gmail.com (Matt Bullock)
Date: Sun, 20 Mar 2016 15:53:40 +0000
Subject: [Cryptography-dev] accessing elliptic curve domain parameters
 (a/b/p/etc)
In-Reply-To: <CAKaOsVyX9Ev4E4OC+VAGCk4pVevt25VhKZKWJWh=-LRNvYwuPg@mail.gmail.com>
References: <CAKaOsVzp=+-dW-v78j9AjYKMJhOMQpPZgsnjU8fNahu87-w+6A@mail.gmail.com>
 <etPan.56a97142.3066f9.ae36@atlas.local>
 <CAKaOsVzR3UhgkxduHvPKrkFEk0AJ=8RQHmWHFspwc0XmUiOFnQ@mail.gmail.com>
 <CAKaOsVyX9Ev4E4OC+VAGCk4pVevt25VhKZKWJWh=-LRNvYwuPg@mail.gmail.com>
Message-ID: <CAKaOsVxm4rAdLsZ1tBaF-Z+mNtAXR=G3FYfg-A=18HK2DwEbrA@mail.gmail.com>

I see that the pull request[1] relevant to this was denied last week due to
the API surface.  For my own understanding, what would be required for
these values to be approved to be available through this library
(cryptography)?  Once I have time I'm planning to contribute the point
compression code that I wrote for my project, but the point decompression
algorithm requires these curve parameter values.

thanks
   --Matt

[1] https://github.com/pyca/cryptography/pull/2499

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

> 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/20160320/09c8af92/attachment.html>

From paul.l.kehrer at gmail.com  Mon Mar 21 18:01:36 2016
From: paul.l.kehrer at gmail.com (Paul Kehrer)
Date: Mon, 21 Mar 2016 18:01:36 -0400
Subject: [Cryptography-dev] PyCA/cryptography 1.3.1 released
Message-ID: <etPan.56f06f41.3fbc6c2a.375@atlas.local>

PyCA/cryptography 1.3.1 was just released to PyPI. This is a minor bugfix release that fixes the following:


* Fixed a bug that caused an AttributeError when using mock to patch some cryptography modules.


-Paul Kehrer (reaperhulk)

From Stephen.Hjerpe at microfocus.com  Thu Mar 31 17:23:59 2016
From: Stephen.Hjerpe at microfocus.com (Stephen Hjerpe)
Date: Thu, 31 Mar 2016 21:23:59 +0000
Subject: [Cryptography-dev] OpenSSL naming permission
Message-ID: <6401DE1AA4435A4BA3EF4D4A0E3D5C8B015DA8FE34@Rock-Exchange1.microfocus.com>

Hi,

My understanding is that the OpenSSL license states, "Products derived from this software may not be called "OpenSSL" nor may "OpenSSL" appear in their names without prior written permission of the OpenSSL Project."

Please provide some reference on the pyOpenSSL site making it clear that this permission has been obtained.

Thanks,

Stephen Hjerpe
Development Manager

stephen.hjerpe at microfocus.com<mailto:your.email at microfous.com>

(661) 821-8917
(858) 354-8146 (mobile)


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