[Cryptography-dev] PyCon & Releases

Thu Dec 19 19:49:18 CET 2013

Doesn't seem like the type of thing that needs to block the initial release.

Alex

On Thu, Dec 19, 2013 at 10:41 AM, Donald Stufft <donald at stufft.io> wrote:

> Having an externally packaged backend would probably be useful in a
> validate that this is actually possible and reasonable to do sort of thing.
>
> On Dec 18, 2013, at 10:36 AM, Alex Gaynor <alex.gaynor at gmail.com> wrote:
>
> Even if this were legally well founded (no clue if it is or not),
> cryptography isn't an end user application, it's linked into the users
> program, and this would make it way too easy for them to shoot themselves
> in the feet.
>
> Alex
>
>
> On Wed, Dec 18, 2013 at 7:35 AM, alexs <alexs at prol.etari.at> wrote:
>
>> 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
>>
>> _______________________________________________
>> 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
>  _______________________________________________
> Cryptography-dev mailing list
> Cryptography-dev at python.org
> https://mail.python.org/mailman/listinfo/cryptography-dev
>
>
>
> -----------------
> Donald Stufft
> PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
>
>
> _______________________________________________
> 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/20131219/2bd2e782/attachment-0001.html>