[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:


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 

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()}]).

And see the same result in 18.3.2:

1> ssl:listen(0, [{ciphers,ssl:cipher_suites()}]).

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