[Cryptography-dev] PyCon & Releases

Alex Gaynor alex.gaynor at gmail.com
Wed Dec 18 16:36:49 CET 2013


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/cryptography-dev/attachments/20131218/99c6bdcb/attachment.html>


More information about the Cryptography-dev mailing list