> On 26 Jan 2017, at 21:17, Donald Stufft <don...@stufft.io> wrote:
>
>
>> On Jan 26, 2017, at 4:18 AM, Cory Benfield <c...@lukasa.co.uk
>> <mailto:c...@lukasa.co.uk>> wrote:
>>
>> For this reason I’m inclined to lean towards the more verbose approach of
>> just writing down what all of the cipher suites are in an enum. That way, it
>> gets much easier to validate what’s going on. There’s still no requirement
>> to actually support them all: an implementation is allowed to quietly ignore
>> any cipher suites it doesn’t support. But that can no longer happen due to
>> typos, because typos now cause AttributeErrors at runtime in a way that is
>> very obvious and clear.
>
>
> I’d say additionally that given the verbose approach a third party library
> could provide this OpenSSL like API and be responsible for “compiling” it
> down to the actual list of ciphers for input into the verbose API. If one of
> those got popular and seemed stable enough to add it, we could always add it
> in later as a higher level API for cipher selection without the backends
> needing to change anything since the output of such a function would still be
> a list of all of the desired ciphers which would be the input to the backends.
Yup, strongly agreed.
Cory
_______________________________________________
Security-SIG mailing list
Security-SIG@python.org
https://mail.python.org/mailman/listinfo/security-sig
