[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