[erlang-questions] Patch package OTP 18.3.2 released
Fred Hebert
mononcqc@REDACTED
Wed Apr 27 19:10:03 CEST 2016
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
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.
More information about the erlang-questions
mailing list