On 2017-09-19 10:30 AM, Glen Willmot wrote:
> Good morning,
>
> Just curious on when we'll see an update on the apache2 release to version
> 2.4.28 to patch against the "Optionsbleed" bug detailed by CVE-2017-9798.
>
> More info on the severity of this bug can be seen at:
>
Based solely on the CVE information, I'd surmise we aren't affected by
CVE-2017-3733, because we don't have any OpenSSL 1.1.0 in the
repositories - anywhere. The original Apache announcement also
indicated that 1.0.2 is not affected, and the Security Team made a note
that only OpenSSL 1.1.x is
On Tue, Sep 19, 2017 at 03:31:22AM +, Eric Yuen wrote:
> I am looking for a contact to reach out in regards
> https://packages.ubuntu.com/trusty/openssl on Trusty and having an update to
> the OpenSSL package updated with CVE-2017-3733
The CVE database reports that Trusty is not affected by
On Tue, Sep 19, 2017 at 10:30:20AM -0400, Glen Willmot wrote:
> Just curious on when we'll see an update on the apache2 release to
> version 2.4.28 to patch against the "Optionsbleed" bug detailed by
> CVE-2017-9798.
Already done, but by backporting the fix (as usual for Linux
distributions)
Hi folks,
I am looking for a contact to reach out in regards
https://packages.ubuntu.com/trusty/openssl on Trusty and having an update to
the OpenSSL package updated with CVE-2017-3733
Please kindly forward a contact, appreciated it.
I reached this contact via
Maintainer:
* Ubuntu
Good morning,
Just curious on when we'll see an update on the apache2 release to version
2.4.28 to patch against the "Optionsbleed" bug detailed by CVE-2017-9798.
More info on the severity of this bug can be seen at:
Robie Basak schreef op 18-09-2017 0:40:
On Mon, Sep 18, 2017 at 12:32:26AM +0200, Göran Hasse wrote:
They must have "forgot it".
In that case, in the first instance upstream should be contacted
directly with this report. Then the problem can be fixed for everyone
without risking confusion to
Göran Hasse schreef op 18-09-2017 0:32:
They must have "forgot it".
An openvpn client service have the same importance as the login
program.
So it should be restarted (with some backoff strategy maybe).
A system service of this importance should *always* be restarted after
a krash! We had
