Erlang/OTP 21.0-rc1 (Release Candidate)

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Fwd: Erlang/OTP 21.0-rc1 (Release Candidate)

Siri Hansen
Sorry - forgot to copy list...

---------- Forwarded message ----------
From: Siri Hansen <[hidden email]>
Date: 2018-05-04 16:44 GMT+02:00
Subject: Re: [erlang-questions] Erlang/OTP 21.0-rc1 (Release Candidate)
To: Svilen Ivanov <[hidden email]>


Hi, thanks for reporting - it should be removing_handler/2 - I will correct it asap.
Regards
/siri

2018-05-03 12:48 GMT+02:00 Svilen Ivanov <[hidden email]>:
In Kernel User's Guide new logger API chapter
"2.6 Example: implement a handler"
callback function 'removing_handler' is documented to accept single
parameter logger:handler_id(),
but in the example for handler that prints to file it takes two
parameters (Id and Config).

The current implementation seems to call this function with single
parameter HandlerId, but that makes not possible to cleanly close the
file descriptor as shown in the example.

So, removing_handler/1 or removing_handler/2 ?

BR, Svilen

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Andreas Schultz-3
In reply to this post by Henrik Nord X
Hi,

The RC breaks rebar3 badly, not sure if it's rebar's fault or a problem with the new logger...

With an up to date rebar3 clone:

    rebar3$ ./bootstrap
    (no logger present) unexpected logger message: {log,error,"Error in process ~p with exit value:~n~p~n",[<0.39.0>,{badarg,[{ets,lookup,[logger,proc_lib],[]},{logger_config,allow,3,[{file,"logger_config.erl"},{line,42}]},{proc_lib,crash_report,4,[{file,"proc_lib.erl"},{line,508}]},{proc_lib,exit_p,3,[{file,"proc_lib.erl"},{line,269}]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.37.0>,pid=><0.39.0>,time=>-576460751953591}}
    (no logger present) unexpected logger message: {log,error,"Error in process ~p with exit value:~n~p~n",[<0.39.0>,{badarg,[{ets,lookup,[logger,proc_lib],[]},{logger_config,allow,3,[{file,"logger_config.erl"},{line,42}]},{proc_lib,crash_report,4,[{file,"proc_lib.erl"},{line,508}]},{proc_lib,exit_p,3,[{file,"proc_lib.erl"},{line,269}]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.37.0>,pid=><0.39.0>,time=>-576460751953591}}
   ...

And so on...

Regards
Andreas

Henrik Nord X <[hidden email]> schrieb am Mi., 2. Mai 2018 um 13:38 Uhr:
OTP 21 Release Candidate 1

This is the first of two planned release candidates before the OTP 21
release. The intention whit this release is that you as users try it
and give us feedback if something does not work as expected. Could be a
bug,an unexpected incompatibility, a significant change of
characteristics in a negative direction, etc. 

Erlang/OTP 21 is a new major release with new features, improvements as
well as incompatibilities.

Potential Incompatibilities

 * All Corba applications are now moved from the OTP repository
    * A new Corba repository will be created https://github.com/erlang
 * New applications ftp and tftp, moved from inets
 * ssl no longer supports 3_DES cipher suites or RSA-key exchange
cipher suites by default
 * erlang:monitor on a primitive node (erl_interface, jinterface, etc)
will no longer fail with badarg exception. Instead a monitor will be
created, but it will only supervise the connection to the node.

 Highlights

 Erts:

    * Enhanced IO scalability
    * Support for usage of distribution controller processes for
      alternative transports, routing etc
    * compact instructions on 64bit systems for code below 4GB 20% less
      memory for loaded code
    * Rewrite of the efile-driver with NIFs and "Dirty schedulers"
      resulting in faster file operations
    * non-smp VM removed
    * link and monitor optimized for scalability
    * os:getenv/putenv now work on thread-safe emulation. No longer in
      sync with libc getenv(3). Manual synchronization will be needed.

Compiler:
    * Misc compiler optimizations including contributions from the
      Elixir team resulting in 10% improvements in benchmarks
    * "Tuple calls" have been removed from the run-time system.
    * Code such as f({ok, Val}) -> {ok, Val} is now automatically
      rewritten to f({ok, Val} = Tuple) -> Tuple. this reduces code
      size, execution time, and removed GC pressure.
    * More information in stacktrace from a number of operators
    * erlang:get_stacktrace/0 deprecated to be replaced with try ...
      catch C:R:Stacktrace -> ...
    * Creation of small maps with literal keys optimized.

Security:
    * DTLS support in SSL
    * Enhanced support for distribution over TLS
    * "unsecure" ciphers removed from defaults in SSL and SSH.
    * A new option value defined to facilitate implementing exec
      servers. Old option kept for compatibility, but now gives errors
      on stderror.

Standard libraries:
    * New API for logging, logger
    * New uri_string module for parsing URIs according to "The
      standard"
    * New function lists:search(list,fun/1) -> {ok, Value} | false
    * Changed default behaviour of .erlang loading. escript, erlc,
      dialyzer and typer no longer load an .erlang at all.

For more details see
http://erlang.org/download/otp_src_21.0-rc1.readme

Pre built versions for Windows can be fetched here:
http://erlang.org/download/otp_win32_21.0-rc1.exe
http://erlang.org/download/otp_win64_21.0-rc1.exe

Online documentation can be browsed here:
http://erlang.org/documentation/doc-10.0-rc1/doc/

The Erlang/OTP source can also be found at GitHub on the official
Erlang repository,
https://github.com/erlang/otp with tag OTP-21.0-rc1


Thank you for all your contributions!
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
--
--
Dipl.-Inform. Andreas Schultz

----------------------- enabling your networks ----------------------
Travelping GmbH                     Phone:  +49-391-81 90 99 0
Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
39108 Magdeburg                     Email:  [hidden email]
GERMANY                             Web:    http://www.travelping.com

Company Registration: Amtsgericht Stendal        Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.: DE236673780
---------------------------------------------------------------------

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Ingela Andin
In reply to this post by Roger Lipscombe-2
Hi!

Thank you for the example

I did find one bug, the patch is here:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..dd3dc54 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,7 +2837,7 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.


my other sslv2 issue seems not to be related. (Probably a OpenSSL issue) Your example does however not work perfect
so I am continuing to look into this!

Regards Ingela Erlang/OTP team - Ericsson AB





2018-05-04 12:25 GMT+02:00 Roger Lipscombe <[hidden email]>:
On 4 May 2018 at 08:32, Ingela Andin <[hidden email]> wrote:
> This error is consistent with one of the errors I am seeing in the nightly
> builds when running OpenSSL with only default parameters so I suspect
> something is off in combination
> version negotiation and cipher suite selection checks. I am looking in to
> it!

I'm seeing the same, if it helps to reproduce. I generated my certificates with:

#!/bin/sh

# Create the CA key and certificate.
openssl genrsa -out ca.key 2048
openssl req -new -x509 -nodes -key ca.key -days 3653 -out ca.pem -subj
"/CN=Test CA"

# Create the server key and CSR.
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=localhost"

# Sign the CSR with the CA key.
serial=$(date +"%s")
openssl x509 -req -days 3563 -CA ca.pem -CAserial $serial
-CAcreateserial -CAkey ca.key -in server.csr -out server.pem
rm $serial

I tested with:

% Server
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
LOpts = [{certfile, "server.pem"}, {keyfile, "server.key"}].
{ok, LSock} = ssl:listen(Port, LOpts).
{ok, CSock} = ssl:transport_accept(LSock).
ok = ssl:ssl_accept(CSock).

% Client
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
COpts = [{verify, verify_peer}, {cacertfile, "ca.pem"}].
{ok, Sock} = ssl:connect("localhost", Port, COpts).

The server reports:

=INFO REPORT==== 4-May-2018::11:22:20.971130 ===
TLS server: In state hello at tls_handshake.erl:130 generated SERVER
ALERT: Fatal - Handshake Failure - malformed_handshake_data

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The client reports:

=INFO REPORT==== 4-May-2018::11:22:20.981524 ===
TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The same code works fine with 20.3.1

Thanks,
Roger.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Tristan Sloughter-4
In reply to this post by Andreas Schultz-3
We cut a new release today, 3.5.2, that builds with 21 fine.

Tristan

On Fri, May 4, 2018, at 7:58 AM, Andreas Schultz wrote:
Hi,

The RC breaks rebar3 badly, not sure if it's rebar's fault or a problem with the new logger...

With an up to date rebar3 clone:

    rebar3$ ./bootstrap
    (no logger present) unexpected logger message: {log,error,"Error in process ~p with exit value:~n~p~n",[<0.39.0>,{badarg,[{ets,lookup,[logger,proc_lib],[]},{logger_config,allow,3,[{file,"logger_config.erl"},{line,42}]},{proc_lib,crash_report,4,[{file,"proc_lib.erl"},{line,508}]},{proc_lib,exit_p,3,[{file,"proc_lib.erl"},{line,269}]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.37.0>,pid=><0.39.0>,time=>-576460751953591}}
    (no logger present) unexpected logger message: {log,error,"Error in process ~p with exit value:~n~p~n",[<0.39.0>,{badarg,[{ets,lookup,[logger,proc_lib],[]},{logger_config,allow,3,[{file,"logger_config.erl"},{line,42}]},{proc_lib,crash_report,4,[{file,"proc_lib.erl"},{line,508}]},{proc_lib,exit_p,3,[{file,"proc_lib.erl"},{line,269}]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.37.0>,pid=><0.39.0>,time=>-576460751953591}}
   ...

And so on...

Regards
Andreas

Henrik Nord X <[hidden email]> schrieb am Mi., 2. Mai 2018 um 13:38 Uhr:
OTP 21 Release Candidate 1

This is the first of two planned release candidates before the OTP 21
release. The intention whit this release is that you as users try it
and give us feedback if something does not work as expected. Could be a
bug,an unexpected incompatibility, a significant change of
characteristics in a negative direction, etc. 

Erlang/OTP 21 is a new major release with new features, improvements as
well as incompatibilities.

Potential Incompatibilities

 * All Corba applications are now moved from the OTP repository
    * A new Corba repository will be created https://github.com/erlang
 * New applications ftp and tftp, moved from inets
 * ssl no longer supports 3_DES cipher suites or RSA-key exchange
cipher suites by default
 * erlang:monitor on a primitive node (erl_interface, jinterface, etc)
will no longer fail with badarg exception. Instead a monitor will be
created, but it will only supervise the connection to the node.

 Highlights

 Erts:

    * Enhanced IO scalability
    * Support for usage of distribution controller processes for
      alternative transports, routing etc
    * compact instructions on 64bit systems for code below 4GB 20% less
      memory for loaded code
    * Rewrite of the efile-driver with NIFs and "Dirty schedulers"
      resulting in faster file operations
    * non-smp VM removed
    * link and monitor optimized for scalability
    * os:getenv/putenv now work on thread-safe emulation. No longer in
      sync with libc getenv(3). Manual synchronization will be needed.

Compiler:
    * Misc compiler optimizations including contributions from the
      Elixir team resulting in 10% improvements in benchmarks
    * "Tuple calls" have been removed from the run-time system.
    * Code such as f({ok, Val}) -> {ok, Val} is now automatically
      rewritten to f({ok, Val} = Tuple) -> Tuple. this reduces code
      size, execution time, and removed GC pressure.
    * More information in stacktrace from a number of operators
    * erlang:get_stacktrace/0 deprecated to be replaced with try ...
      catch C:R:Stacktrace -> ...
    * Creation of small maps with literal keys optimized.

Security:
    * DTLS support in SSL
    * Enhanced support for distribution over TLS
    * "unsecure" ciphers removed from defaults in SSL and SSH.
    * A new option value defined to facilitate implementing exec
      servers. Old option kept for compatibility, but now gives errors
      on stderror.

Standard libraries:
    * New API for logging, logger
    * New uri_string module for parsing URIs according to "The
      standard"
    * New function lists:search(list,fun/1) -> {ok, Value} | false
    * Changed default behaviour of .erlang loading. escript, erlc,
      dialyzer and typer no longer load an .erlang at all.

For more details see

Pre built versions for Windows can be fetched here:

Online documentation can be browsed here:

The Erlang/OTP source can also be found at GitHub on the official
Erlang repository,
https://github.com/erlang/otp with tag OTP-21.0-rc1


Thank you for all your contributions!
_______________________________________________
erlang-questions mailing list
--
--
Dipl.-Inform. Andreas Schultz

----------------------- enabling your networks ----------------------
Travelping GmbH                     Phone:  +49-391-81 90 99 0
Roentgenstr. 13                     Fax:    +49-391-81 90 99 299
39108 Magdeburg                     Email:  [hidden email]
GERMANY                             Web:    http://www.travelping.com

Company Registration: Amtsgericht Stendal        Reg No.:   HRB 10578
Geschaeftsfuehrer: Holger Winkelmann          VAT ID No.: DE236673780
---------------------------------------------------------------------
_______________________________________________
erlang-questions mailing list


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Ingela Andin
In reply to this post by Ingela Andin
I hope this hole fix please try it out:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..ed8663b 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,11 +2837,13 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.
 
+filter_keyuse_suites(_, [], CipherSuits, _) ->
+    CipherSuits;
 filter_keyuse_suites(Use, KeyUse, CipherSuits, Suites) ->
     case ssl_certificate:is_valid_key_usage(KeyUse, Use) of
     true ->


Regards Ingela Erlang/OTP Team - Ericsson AB



2018-05-04 17:41 GMT+02:00 Ingela Andin <[hidden email]>:
Hi!

Thank you for the example

I did find one bug, the patch is here:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..dd3dc54 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,7 +2837,7 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.


my other sslv2 issue seems not to be related. (Probably a OpenSSL issue) Your example does however not work perfect
so I am continuing to look into this!

Regards Ingela Erlang/OTP team - Ericsson AB





2018-05-04 12:25 GMT+02:00 Roger Lipscombe <[hidden email]>:
On 4 May 2018 at 08:32, Ingela Andin <[hidden email]> wrote:
> This error is consistent with one of the errors I am seeing in the nightly
> builds when running OpenSSL with only default parameters so I suspect
> something is off in combination
> version negotiation and cipher suite selection checks. I am looking in to
> it!

I'm seeing the same, if it helps to reproduce. I generated my certificates with:

#!/bin/sh

# Create the CA key and certificate.
openssl genrsa -out ca.key 2048
openssl req -new -x509 -nodes -key ca.key -days 3653 -out ca.pem -subj
"/CN=Test CA"

# Create the server key and CSR.
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=localhost"

# Sign the CSR with the CA key.
serial=$(date +"%s")
openssl x509 -req -days 3563 -CA ca.pem -CAserial $serial
-CAcreateserial -CAkey ca.key -in server.csr -out server.pem
rm $serial

I tested with:

% Server
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
LOpts = [{certfile, "server.pem"}, {keyfile, "server.key"}].
{ok, LSock} = ssl:listen(Port, LOpts).
{ok, CSock} = ssl:transport_accept(LSock).
ok = ssl:ssl_accept(CSock).

% Client
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
COpts = [{verify, verify_peer}, {cacertfile, "ca.pem"}].
{ok, Sock} = ssl:connect("localhost", Port, COpts).

The server reports:

=INFO REPORT==== 4-May-2018::11:22:20.971130 ===
TLS server: In state hello at tls_handshake.erl:130 generated SERVER
ALERT: Fatal - Handshake Failure - malformed_handshake_data

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The client reports:

=INFO REPORT==== 4-May-2018::11:22:20.981524 ===
TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The same code works fine with 20.3.1

Thanks,
Roger.



_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Kostis Sagonas-2
In reply to this post by Andreas Schultz-3
On 05/04/2018 04:58 PM, Andreas Schultz wrote:

> Hi,
>
> The RC breaks rebar3 badly, not sure if it's rebar's fault or a problem
> with the new logger...
>
> With an up to date rebar3 clone:
>
>      rebar3$ ./bootstrap
>    (no logger present) unexpected logger message: {log,error,"Error in
> process ~p with exit
> value:~n~p~n",[<0.39.0>,{badarg,[{ets,lookup,[logger,proc_lib],[]},{logger_config,allow,3,[{file,"logger_config.erl"},{line,42}]},{proc_lib,crash_report,4,[{file,"proc_lib.erl"},{line,508}]},{proc_lib,exit_p,3,[{file,"proc_lib.erl"},{line,269}]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.37.0>,pid=><0.39.0>,time=>-576460751953591}}
>    (no logger present) unexpected logger message: {log,error,"Error in
> process ~p with exit
> value:~n~p~n",[<0.39.0>,{badarg,[{ets,lookup,[logger,proc_lib],[]},{logger_config,allow,3,[{file,"logger_config.erl"},{line,42}]},{proc_lib,crash_report,4,[{file,"proc_lib.erl"},{line,508}]},{proc_lib,exit_p,3,[{file,"proc_lib.erl"},{line,269}]}]}],#{error_logger=>#{emulator=>true,tag=>error},gl=><0.37.0>,pid=><0.39.0>,time=>-576460751953591}}
>     ...
>
> And so on...

FWIW, I experienced this problem last Friday when I updated my copy of
OTP's 'master' branch, and built starting from a 'make clean'.  These
errors were there with me all the time.  Note that this has nothing to
do with 'rebar*'.  I was just trying to run the HiPE tests with ct_run.

Then I spent about two hours investigating what the issue could be and
did not really get anywhere.  Then I tried a clean git checkout of OTP
and that built a version that did not spit any such errors.  Turns out
that this issue can also be fixed by just zapping all generated files
under 'bin' and then re-building everything:

        cd otp
        /bin/rm -r bin
        git checkout -- bin

        ./otp_build autoconf ; ./configure ... ; make   // build again

[I did not investigate further which exact file under bin was the culprit.]

Perhaps the issue you are facing is similar and can be solved in a
similar way.

Kostis


PS. A suggestion to the OTP folks:

If there is no intention of fixing the 'make clean' target to work
properly, why don't you just remove it so that there is less confusion?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Michał Muskała
In reply to this post by Henrik Nord X
The release looks great. Thank you to the whole OTP team for the work you put into it.

I wonder about the new file implementation that uses NIFs instead of ports, specifically the instrumentation around it. With ports, there was a way to list all ports and filter those that are files. This proved sometimes useful in debugging situations. Would it be possible to also get some kind of API to list all opened files, possibly with some additional information (like path)?
I imagine a need for an API like that would be even more pressing once sockets are ported to use NIFs instead of ports as well.

Michał.

On 2 May 2018, 13:38 +0200, Henrik Nord X <[hidden email]>, wrote:
OTP 21 Release Candidate 1

This is the first of two planned release candidates before the OTP 21
release. The intention whit this release is that you as users try it
and give us feedback if something does not work as expected. Could be a
bug,an unexpected incompatibility, a significant change of
characteristics in a negative direction, etc. 

Erlang/OTP 21 is a new major release with new features, improvements as
well as incompatibilities.

Potential Incompatibilities

 * All Corba applications are now moved from the OTP repository
    * A new Corba repository will be created https://github.com/erlang
 * New applications ftp and tftp, moved from inets
 * ssl no longer supports 3_DES cipher suites or RSA-key exchange
cipher suites by default
 * erlang:monitor on a primitive node (erl_interface, jinterface, etc)
will no longer fail with badarg exception. Instead a monitor will be
created, but it will only supervise the connection to the node.

 Highlights

 Erts:

    * Enhanced IO scalability
    * Support for usage of distribution controller processes for
      alternative transports, routing etc
    * compact instructions on 64bit systems for code below 4GB 20% less
      memory for loaded code
    * Rewrite of the efile-driver with NIFs and "Dirty schedulers"
      resulting in faster file operations
    * non-smp VM removed
    * link and monitor optimized for scalability
    * os:getenv/putenv now work on thread-safe emulation. No longer in
      sync with libc getenv(3). Manual synchronization will be needed.

Compiler:
    * Misc compiler optimizations including contributions from the
      Elixir team resulting in 10% improvements in benchmarks
    * "Tuple calls" have been removed from the run-time system.
    * Code such as f({ok, Val}) -> {ok, Val} is now automatically
      rewritten to f({ok, Val} = Tuple) -> Tuple. this reduces code
      size, execution time, and removed GC pressure.
    * More information in stacktrace from a number of operators
    * erlang:get_stacktrace/0 deprecated to be replaced with try ...
      catch C:R:Stacktrace -> ...
    * Creation of small maps with literal keys optimized.

Security:
    * DTLS support in SSL
    * Enhanced support for distribution over TLS
    * "unsecure" ciphers removed from defaults in SSL and SSH.
    * A new option value defined to facilitate implementing exec
      servers. Old option kept for compatibility, but now gives errors
      on stderror.

Standard libraries:
    * New API for logging, logger
    * New uri_string module for parsing URIs according to "The
      standard"
    * New function lists:search(list,fun/1) -> {ok, Value} | false
    * Changed default behaviour of .erlang loading. escript, erlc,
      dialyzer and typer no longer load an .erlang at all.

For more details see
http://erlang.org/download/otp_src_21.0-rc1.readme

Pre built versions for Windows can be fetched here:
http://erlang.org/download/otp_win32_21.0-rc1.exe
http://erlang.org/download/otp_win64_21.0-rc1.exe

Online documentation can be browsed here:
http://erlang.org/documentation/doc-10.0-rc1/doc/

The Erlang/OTP source can also be found at GitHub on the official
Erlang repository,
https://github.com/erlang/otp with tag OTP-21.0-rc1


Thank you for all your contributions!
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Fred Hebert-2
In reply to this post by Tristan Sloughter-4
On 05/04, Tristan Sloughter wrote:
>We cut a new release today, 3.5.2, that builds with 21 fine.
>

Caveat: CT output is broken. You have to run `rebar3 ct
--readable=false`

The problem is that we still support R16 until 21 lands, and we can't
support the logger API without support for maps since all of its
messages are maps.

I've made a branch of the app used to redirect CT Output at
https://github.com/ferd/cth_readable/pull/18
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Ingela Andin
In reply to this post by Ingela Andin
Hi again!

I think I need to take back that last change, it is a bit more complicated. I will work on a real fix during the week.

Regards Ingela Erlang/OTP Team 

2018-05-04 19:18 GMT+02:00 Ingela Andin <[hidden email]>:
I hope this hole fix please try it out:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..ed8663b 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,11 +2837,13 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.
 
+filter_keyuse_suites(_, [], CipherSuits, _) ->
+    CipherSuits;
 filter_keyuse_suites(Use, KeyUse, CipherSuits, Suites) ->
     case ssl_certificate:is_valid_key_usage(KeyUse, Use) of
     true ->


Regards Ingela Erlang/OTP Team - Ericsson AB



2018-05-04 17:41 GMT+02:00 Ingela Andin <[hidden email]>:
Hi!

Thank you for the example

I did find one bug, the patch is here:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..dd3dc54 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,7 +2837,7 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.


my other sslv2 issue seems not to be related. (Probably a OpenSSL issue) Your example does however not work perfect
so I am continuing to look into this!

Regards Ingela Erlang/OTP team - Ericsson AB





2018-05-04 12:25 GMT+02:00 Roger Lipscombe <[hidden email]>:
On 4 May 2018 at 08:32, Ingela Andin <[hidden email]> wrote:
> This error is consistent with one of the errors I am seeing in the nightly
> builds when running OpenSSL with only default parameters so I suspect
> something is off in combination
> version negotiation and cipher suite selection checks. I am looking in to
> it!

I'm seeing the same, if it helps to reproduce. I generated my certificates with:

#!/bin/sh

# Create the CA key and certificate.
openssl genrsa -out ca.key 2048
openssl req -new -x509 -nodes -key ca.key -days 3653 -out ca.pem -subj
"/CN=Test CA"

# Create the server key and CSR.
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=localhost"

# Sign the CSR with the CA key.
serial=$(date +"%s")
openssl x509 -req -days 3563 -CA ca.pem -CAserial $serial
-CAcreateserial -CAkey ca.key -in server.csr -out server.pem
rm $serial

I tested with:

% Server
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
LOpts = [{certfile, "server.pem"}, {keyfile, "server.key"}].
{ok, LSock} = ssl:listen(Port, LOpts).
{ok, CSock} = ssl:transport_accept(LSock).
ok = ssl:ssl_accept(CSock).

% Client
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
COpts = [{verify, verify_peer}, {cacertfile, "ca.pem"}].
{ok, Sock} = ssl:connect("localhost", Port, COpts).

The server reports:

=INFO REPORT==== 4-May-2018::11:22:20.971130 ===
TLS server: In state hello at tls_handshake.erl:130 generated SERVER
ALERT: Fatal - Handshake Failure - malformed_handshake_data

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The client reports:

=INFO REPORT==== 4-May-2018::11:22:20.981524 ===
TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The same code works fine with 20.3.1

Thanks,
Roger.




_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Lukas Larsson-8
In reply to this post by Michał Muskała
Hello,

On Fri, May 4, 2018 at 7:23 PM, Michał Muskała <[hidden email]> wrote:
The release looks great. Thank you to the whole OTP team for the work you put into it.

Thanks!
 

I wonder about the new file implementation that uses NIFs instead of ports, specifically the instrumentation around it. With ports, there was a way to list all ports and filter those that are files. This proved sometimes useful in debugging situations. Would it be possible to also get some kind of API to list all opened files, possibly with some additional information (like path)?
I imagine a need for an API like that would be even more pressing once sockets are ported to use NIFs instead of ports as well.

Yes, I also believe that something like this is going to be needed. While it is possible on most OSs to look in the /proc/ fs to see which files are opened, it is definitely useful to be able to track back to the process controlling it. Even more so for sockets.

Personally I would prefer not to have to build something new within erts to handle this, but instead use what we have. Maybe ets tables that keeps track of files, connections, etc. 

Each sockets will most likely have to be associated with a process, so for them it could be possible to just store something in the process dictionary and let the debug process get the pdict of all processes.

Lukas


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Jesper Louis Andersen-2
I'm assuming that it is expected behavior that the 21-rc1 tarball was removed from the downloads directory (The windows binaries are still there btw, as is the README).

I found this because I ran `kerl update releases` and to my surprise it wasn't there today, whereas in the weekend it was.

Is this an oversight, or should I await further development as things need to move around some more?

On Mon, May 7, 2018 at 10:00 AM Lukas Larsson <[hidden email]> wrote:
Hello,

On Fri, May 4, 2018 at 7:23 PM, Michał Muskała <[hidden email]> wrote:
The release looks great. Thank you to the whole OTP team for the work you put into it.

Thanks!
 

I wonder about the new file implementation that uses NIFs instead of ports, specifically the instrumentation around it. With ports, there was a way to list all ports and filter those that are files. This proved sometimes useful in debugging situations. Would it be possible to also get some kind of API to list all opened files, possibly with some additional information (like path)?
I imagine a need for an API like that would be even more pressing once sockets are ported to use NIFs instead of ports as well.

Yes, I also believe that something like this is going to be needed. While it is possible on most OSs to look in the /proc/ fs to see which files are opened, it is definitely useful to be able to track back to the process controlling it. Even more so for sockets.

Personally I would prefer not to have to build something new within erts to handle this, but instead use what we have. Maybe ets tables that keeps track of files, connections, etc. 

Each sockets will most likely have to be associated with a process, so for them it could be possible to just store something in the process dictionary and let the debug process get the pdict of all processes.

Lukas

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Erlang/OTP 21.0-rc1 (Release Candidate)

Ingela Andin
In reply to this post by Ingela Andin
Hi!

Finally a solution:

https://github.com/erlang/otp/pull/1820

Regards Ingela Erlang/OTP team - Ericsson AB

2018-05-07 8:55 GMT+02:00 Ingela Andin <[hidden email]>:
Hi again!

I think I need to take back that last change, it is a bit more complicated. I will work on a real fix during the week.

Regards Ingela Erlang/OTP Team 


2018-05-04 19:18 GMT+02:00 Ingela Andin <[hidden email]>:
I hope this hole fix please try it out:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..ed8663b 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,11 +2837,13 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.
 
+filter_keyuse_suites(_, [], CipherSuits, _) ->
+    CipherSuits;
 filter_keyuse_suites(Use, KeyUse, CipherSuits, Suites) ->
     case ssl_certificate:is_valid_key_usage(KeyUse, Use) of
     true ->


Regards Ingela Erlang/OTP Team - Ericsson AB



2018-05-04 17:41 GMT+02:00 Ingela Andin <[hidden email]>:
Hi!

Thank you for the example

I did find one bug, the patch is here:

diff --git a/lib/ssl/src/ssl_cipher.erl b/lib/ssl/src/ssl_cipher.erl
index 0956d35..dd3dc54 100644
--- a/lib/ssl/src/ssl_cipher.erl
+++ b/lib/ssl/src/ssl_cipher.erl
@@ -2837,7 +2837,7 @@ key_uses(OtpCert) ->
     Extensions = ssl_certificate:extensions_list(TBSExtensions),
     case ssl_certificate:select_extension(?'id-ce-keyUsage', Extensions) of
     undefined ->
-        undefined;
+        [];
     #'Extension'{extnValue = KeyUses} ->
             KeyUses
     end.


my other sslv2 issue seems not to be related. (Probably a OpenSSL issue) Your example does however not work perfect
so I am continuing to look into this!

Regards Ingela Erlang/OTP team - Ericsson AB





2018-05-04 12:25 GMT+02:00 Roger Lipscombe <[hidden email]>:
On 4 May 2018 at 08:32, Ingela Andin <[hidden email]> wrote:
> This error is consistent with one of the errors I am seeing in the nightly
> builds when running OpenSSL with only default parameters so I suspect
> something is off in combination
> version negotiation and cipher suite selection checks. I am looking in to
> it!

I'm seeing the same, if it helps to reproduce. I generated my certificates with:

#!/bin/sh

# Create the CA key and certificate.
openssl genrsa -out ca.key 2048
openssl req -new -x509 -nodes -key ca.key -days 3653 -out ca.pem -subj
"/CN=Test CA"

# Create the server key and CSR.
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/CN=localhost"

# Sign the CSR with the CA key.
serial=$(date +"%s")
openssl x509 -req -days 3563 -CA ca.pem -CAserial $serial
-CAcreateserial -CAkey ca.key -in server.csr -out server.pem
rm $serial

I tested with:

% Server
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
LOpts = [{certfile, "server.pem"}, {keyfile, "server.key"}].
{ok, LSock} = ssl:listen(Port, LOpts).
{ok, CSock} = ssl:transport_accept(LSock).
ok = ssl:ssl_accept(CSock).

% Client
{ok, _} = application:ensure_all_started(ssl).
Port = 11002.
COpts = [{verify, verify_peer}, {cacertfile, "ca.pem"}].
{ok, Sock} = ssl:connect("localhost", Port, COpts).

The server reports:

=INFO REPORT==== 4-May-2018::11:22:20.971130 ===
TLS server: In state hello at tls_handshake.erl:130 generated SERVER
ALERT: Fatal - Handshake Failure - malformed_handshake_data

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The client reports:

=INFO REPORT==== 4-May-2018::11:22:20.981524 ===
TLS client: In state hello received SERVER ALERT: Fatal - Handshake Failure

** exception error: no match of right hand side value
{error,{tls_alert,"handshake failure"}}

The same code works fine with 20.3.1

Thanks,
Roger.





_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
12