[erlang-questions] Patch package OTP 18.3.2 released

[Ingela Andin]

Hi!

2016-04-27 19:10 GMT+02:00 Fred Hebert <mononcqc@REDACTED>:

> On 04/27, Ingela Andin wrote:
>
>> We promise to be backwards compatible, not bug compatible.
>>
>
> I feel I should expand on that.
>
> Right now I have a list of specified SSL ciphers of the form:
>
> {ecdhe_ecdsa,aes_256_gcm,null,sha384}
> {ecdhe_ecdsa,aes_256_cbc,sha384,sha384}
> {ecdhe_ecdsa,aes_256_cbc,sha384},
> ...
> {rsa,aes_256_gcm,null,sha384}
> {rsa,aes_256_gcm,null}
> {rsa,aes_256_cbc,sha256}
>
> You'll note that this list contains some ciphers that may or may not
> contain the GCM component in them. The thing I'm doing then is that because
> GCM support is dependent upon platform and OpenSSL version (i.e.  OSX by
> default does not ship with support for ecliptic curve + GCM mode, but does
> so on other versions), I will do either of the following things:
>
> 1. Filter out ciphersuites not supported by the VM
>

There is an internal  function in ssl that does that
ssl_cipher:filter_suites/1. It is used when the cipher option is not set to
filter out suites from the default value that may not have support by
crypto.
I am thinking maybe it should be applied to the users option too and return
an error if it becomes empty, or maybe make a new API function?!




> 2. Mandate some ciphersuites to be supported for the app to boot.
>
> Prior to 18.3, the easiest way to do that was to compare the values
> given to what was being returned by `ssl:cipher_suites()': if the value
> was in, it was supported by the VM.
>
> Starting with 18.3, this started breaking since I had to check for 4-tuple
> support in there to make sure that a 3-tuple wasn't being passed where a
> 4-tuple was required and the opposite. THat's okay, I can work with that.
>
> The problem is that starting with 18.3.2, `ssl:cipher_suites()' returns a
> 4-tuple whether this format is actually being supported or not.
>
> This means that there isn't any way for me to configure things in any
> dynamic manner whatsoever, since I cannot validate which ciphersuite
> configurations are supported by using the functionality of the SSL library
> itself.
>
> See the following example in 18.3:
>
> 1> ssl:listen(0, [{ciphers,ssl:cipher_suites()}]).
> {ok,{sslsocket,...}}
>
> And see the same result in 18.3.2:
>
> 1> ssl:listen(0, [{ciphers,ssl:cipher_suites()}]).
> {error,{options,{ciphers,[{ecdhe_ecdsa,aes_256_gcm,null,
>                                       sha384},
>                          ...
>                          {ecdh_rsa,...},
>                          {...}|...]}}}
>
> Maybe there's something I'm not getting, but it seems to me that the bug
> is in 18.3.2, not in the other versions.
>


Humm there seems to be something missing from this patch that is present in
master.  I will look into if your PR if it is
the correct fix  or what would be. Of course we will fix this.


Regards Ingela Erlang/OTP team - Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160428/e0dc2630/attachment.htm>