[erlang-questions] Patch Package: OTP 19.3.6.4
Sverker Eriksson
sverker.eriksson@REDACTED
Thu Nov 30 22:06:26 CET 2017
All announced patches on 19 will have versions OTP-19.3.6.x
Any other pushed OTP-19 tag is some sort of special customer request
of backporting fix or feature.
If something is fixed for example on OTP-19.2.y.z, then it will also
be fixed or already have been fixed on OTP-19.3.6.x.
/Sverker
On tor, 2017-11-30 at 12:15 -0800, derek wrote:
> 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
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
More information about the erlang-questions
mailing list