[Cryptography-dev] PyCon & Releases

[alexs]

On 18.12.2013 15:14, Alex Gaynor wrote:

> PolarSSL is GPL, so we almost certainly can't include it as part of
> cryptography itself (I'm not a lawyer, this isn't legal advice, etc.)

I hadn't looked into the license in much detail but it turns out 
they've found a way to make dual-licensed GPL libraries even more 
annoying.

They have some sort of "FOSS License Exception" thing that I think
is intended to make it clear that using PolarSSL within a BSD, APL etc 
app is acceptable?

https://polarssl.org/foss-license-exception

Which mostly seems fair, except for this innovation:

> The Derivative Work does not include any work licensed under the GPL 
> other than the Program;

Which I guess means if you wanted to also support another project that 
had a similar GPL linking exception in you would void this license?

Probably best not to try and support this in the main tree for now :-/

> On Wed, Dec 18, 2013 at 2:32 AM, alexs <alexs at prol.etari.at [7]> 
> wrote:
>
>> On 17.12.2013 19:33, David Reid wrote:
>>
>>> From: Jarret Raim Jarret Raim [1]
>>> Reply: cryptography-dev at python.org [1] cryptography-dev at python.org
>>> [2][2]
>>>
>>> Date: December 17, 2013 at 10:47:41 AM To:
>>> cryptography-dev at python.org [3] cryptography-dev at python.org [4][3]
>>>
>>> Subject: [Cryptography-dev] PyCon & Releases
>>>
>>>> All,
>>>>
>>>> Paul (reaperhulk) and I got accepted to do a talk on the ŒState
>>>> of
>>>> Crypto
>>>> in Python¹. Here is the abstract for our talk:
>>
>> Congratulations :)
>>
>>>
>>
>> As part of this effort, Paul, Donald (dstufft) and I were talking a
>> bit
>>
>> about what a release before PyCon would look like. As PyCon is in
>> April,
>> we don¹t have a l
>>
>>> .
>>>
>>> We came up with 5 areas we wanted to work on pre-release.
>>>
>>> 1. Recipes
>>>
>>> We need to define some of the high level API that consumers would
>>> actually
>>> use. We focused on a two options, hashing and symmetric encryption.
>>>
>>> - Hashing primitives & HMAC
>>> Does this mean stdlib compatible hash/hmac interfaces? I would like
>>> to see this also. The stdlib API is fairly sane. I think the
>>> main blocker on this is likely to be working out what algorithms 
>>> the
>>> chosen backend
>>> actually supports for populating hashlib.algorithms and making
>>> hashlib.new work?
>>>
>>> AIUI we don't make any effort to detect support currently so if 
>>> some
>>> enterprising individual decides to compile OpenSSL with e.g
>> O_MD5
>> we won't throw errors until someone actually attempts to hash
>> something.
>>
>> - Non-framed, authenticated encryption: GCM for small files.
>> The Fernet implementation is also probably ready to land.
>>
>> I'm kind of wary of over specifying our own cryptographic protocols.
>> And
>> it's not clear to me that the tradeoffs between GCM and CBC-HMAC
>>
>>> er-left: 1px #ccc solid; padding-left: 1ex;">- Framed, 
>>> authenticated
>>> encryption: GCM for large files. Possibly
>>> includes
>>> a custom wire format. I think the goal here is a prototype for
>>> review
>>> rather than something that is usable.
>>> It'd be nice if all high level recipes which are not implemented 
>>> for
>>> specific compatibility reasons have the capacity for cryptographic
>>> agility. I might be misunderstanding this but I'm not sure what the
>>> motivation is for adding our own protocols.
>>>
>>> Are there any particular use cases we are targeting that aren't
>>> served by supporting existing
>>> specifications?
>>>
>>> 2. Backends
>> like to land at least one new backend. This would help verify that
>> our API is reasonable and nothing OpenSSL specific has managed to
>> creep
>> into the system. The options we came up with are below. We stayed 
>> away
>> from C++ since CFFI.
>>
>> - CommonCrypto: Land the osx backend. Requires fixes for the testing
>> infrastructure.
>> This is the closest
>>
>>> t: 1ex;">- NSS: Easier backend to land as it works on Travis and is
>>> C, but isn¹t
>>> written yet.
>>> Also, none of the crypto primitives appear to be documented public
>>> API.
>>>
>>>> https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs [5] "NSS
>>>> Public Functions" is strictly SSL stuff.
>>> Botan and PolarSSL look like good candidates in terms of being
>>> actually decent crypto libraries.
>>>
>>> I don't know much about Windows. Does DPAPI offer some handy key
>>> management stuff or something else that might make people actually
>>> want to use it?
>>>
>> _______________________________________________
>> Cryptography-dev mailing list
>> Cryptography-dev at python.org [6]
>> https://mail.python.org/mailman/l
>>
>>>
>
> --
>
> "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



Links:
------
[1] mailto:cryptography-dev at python.org
[2] mailto:cryptography-dev at python.org
[3] mailto:cryptography-dev at python.org
[4] mailto:cryptography-dev at python.org
[5] https://developer.mozilla.org/en-US/docs/NSS#NSS_APIs
[6] mailto:Cryptography-dev at python.org
[7] mailto:alexs at prol.etari.at