[erlang-questions] Patch Package: OTP 19.3.6.4

[derek]

To Ingela and if sverker also on the list:

This morning I just found OTP-19.2.3.1 release is available, for the
only changed application is erts-8.2.2.1;  I'm trying to understand
why is this needed? when you already have OTP 19.3.6.3 which included
erts-8.3.5.3;
how many users are there sticking with 19.2 and can upgrade
19.2.X.Y.latest but can't upgrade to 19.3.X.Y.latest  ?
as a downstream OS distribution packager, I want to know if this need
a packaging as well

Could you also talk on what are the Erlang OTP release rules? if not
have recorded on some link? and what's the maintenance plan for each
past release? how long will each release be supported? like 19 will be
supported till Month-Year? 18 till what Month-Year?   and is 17
already no longer maintained?


https://github.com/erlang/otp/releases
https://github.com/erlang/otp/releases/tag/OTP-19.2.3.1

=== OTP-19.2.3.1 ===

 sverker tagged this a day ago · 4766 commits to master since this tag

Changed Applications:
- erts-8.2.2.1

On Thu, Nov 23, 2017 at 7:26 AM, Ingela Anderton Andin
<Ingela.Anderton.Andin@REDACTED> wrote:
> Patch Package:    OTP 19.3.6.4
> Git Tag:                OTP-19.3.6.4
> Date:                    2017-11-23
> Trouble Report Id:  OTP-14748
> Seq num:
> System:                  OTP
> Release:                 19
> Application:            ssl-8.1.3.1
> Predecessor:          OTP 19.3.6.3
>
>  Check out the git tag OTP-19.3.6.4, and build a full OTP system
>  including documentation. Apply one or more applications from this
>  build as patches to your installation using the 'otp_patch_apply'
>  tool. For information on install requirements, see descriptions for
>  each application version below.
>
>  ---------------------------------------------------------------------
>  --- ssl-8.1.3.1 -----------------------------------------------------
>  ---------------------------------------------------------------------
>
>  Note! The ssl-8.1.3.1 application can *not* be applied independently
>        of other applications on an arbitrary OTP 19 installation.
>
>        On a full OTP 19 installation, also the following runtime
>        dependency has to be satisfied:
>        -- stdlib-3.2 (first satisfied in OTP 19.2)
>
>
>  --- Fixed Bugs and Malfunctions ---
>
>   OTP-14748    Application(s): ssl
>
>                An erlang TLS server configured with cipher suites
>                using rsa key exchange, may be vulnerable to an
>                Adaptive Chosen Ciphertext attack (AKA Bleichenbacher
>                attack) against RSA, which when exploited, may result
>                in plaintext recovery of encrypted messages and/or a
>                Man-in-the-middle (MiTM) attack, despite the attacker
>                not having gained access to the server’s private key
>                itself. CVE-2017-1000385
>
>                Exploiting this vulnerability to perform plaintext
>                recovery of encrypted messages will, in most practical
>                cases, allow an attacker to read the plaintext only
>                after the session has completed. Only TLS sessions
>                established using RSA key exchange are vulnerable to
>                this attack.
>
>                Exploiting this vulnerability to conduct a MiTM attack
>                requires the attacker to complete the initial attack,
>                which may require thousands of server requests, during
>                the handshake phase of the targeted session within the
>                window of the configured handshake timeout. This attack
>                may be conducted against any TLS session using RSA
>                signatures, but only if cipher suites using RSA key
>                exchange are also enabled on the server. The limited
>                window of opportunity, limitations in bandwidth, and
>                latency make this attack significantly more difficult
>                to execute.
>
>                RSA key exchange is enabled by default although least
>                prioritized if server order is honored. For such a
>                cipher suite to be chosen it must also be supported by
>                the client and probably the only shared cipher suite.
>
>                Captured TLS sessions encrypted with ephemeral cipher
>                suites (DHE or ECDHE) are not at risk for subsequent
>                decryption due to this vulnerability.
>
>                As a workaround if default cipher suite configuration
>                was used you can configure the server to not use
>                vulnerable suites with the ciphers option like this:
>
>                {ciphers, [Suite || Suite <- ssl:cipher_suites(),
>                element(1,Suite) =/= rsa]}
>
>                that is your code will look somethingh like this:
>
>                ssl:listen(Port, [{ciphers, [Suite || Suite <-
>                ssl:cipher_suites(), element(1,S) =/= rsa]} |
>                Options]).
>
>                Thanks to Hanno Böck, Juraj Somorovsky and Craig Young
>                for reporting this vulnerability.
>
>
>  Full runtime dependencies of ssl-8.1.3.1: crypto-3.3, erts-7.0,
>  inets-5.10.7, kernel-3.0, public_key-1.2, stdlib-3.2
>
>
>  ---------------------------------------------------------------------
>  ---------------------------------------------------------------------
>  ---------------------------------------------------------------------
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>