@nodejs/release
https://mta.openssl.org/pipermail/openssl-announce/2018-August/000129.html
Forthcoming OpenSSL releases
============================
The OpenSSL project team would like to announce the forthcoming release
of OpenSSL versions 1.1.0i and 1.0.2p.
These releases will be made available on 14th August 2018 between
approximately 1200-1600 UTC.
These are bug-fix releases. They also contain the fixes for two LOW
severity security issues (CVE-2018-0732 and CVE-2018-0737) which were
previously announced here:
https://www.openssl.org/news/secadv/20180612.txt
https://www.openssl.org/news/secadv/20180416.txt
Yours
The OpenSSL Project Team
So we have CVE-2018-0732 in already in 10.x/master, we floated it @ 772d390746.
We also floated 831821bcf, the ECDSA blinding attack that didn't get a CVE AFAIK. It's also not listed in this advisory, perhaps they're considering it below their threshold even for "Low".
I wasn't aware of CVE-2018-0737, that's:
Cache timing vulnerability in RSA Key Generation (CVE-2018-0737)
================================================================
Severity: Low
The OpenSSL RSA Key generation algorithm has been shown to be vulnerable to a
cache timing side channel attack. An attacker with sufficient access to mount
cache timing attacks during the RSA key generation process could recover the
private key.
I think 2018 is going to be defined by various creative and difficult side-channel attacks. We're going to want to get this one out but I wouldn't call it "critical", just something we might expect pressure on if we don't get it out within a few days. We should probably released patched versions of LTS and then bundle this into the next regular 10.x release.
@rvagg can this go out in a regular LTS release? We have a backlog of 6.x changes.
@MylesBorins it looks like we didn't float the other patches on anything but master/v10.x so it probably should be a discrete security release, but there's no reason we couldn't bump them up against eachother. Security release followed quickly by a proper 6.x and 8.x (that's pending isn't it?).
I could take LTS releases for this if we can get someone else to do the 1.0.2 patching. Then I'd say proceed with 6.x and 8.x as planned/normal. I've been hearing we have stuff queued but not pushed out, are we following a schedule anymore or are we too stretched on people-time? Do I need to step up and do a standard LTS release or two?
We have an 8.x proposal put together rn, targeting a Sept 4 release
6.x has a handful of patches on staging, but as we are in maintenance we
haven't planned anything releases
On Wed, Aug 8, 2018, 9:08 PM Rod Vagg notifications@github.com wrote:
@MylesBorins https://github.com/MylesBorins it looks like we didn't
float the other patches on anything but master/v10.x so it probably should
be a discrete security release, but there's no reason we couldn't bump them
up against eachother. Security release followed quickly by a proper 6.x and
8.x (that's pending isn't it?).I could take LTS releases for this if we can get someone else to do the
1.0.2 patching. Then I'd say proceed with 6.x and 8.x as planned/normal.
I've been hearing we have stuff queued but not pushed out, are we following
a schedule anymore or are we too stretched on people-time? Do I need to
step up and do a standard LTS release or two?—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/node/issues/22187#issuecomment-411604448, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAecV_l3F14qYqzRAsjEZK-NUrTqI7WRks5uO4uTgaJpZM4VzSiF
.
@MylesBorins would you like me to take one of these? Maybe I could queue up a 6.x maintenance with what's on staging in the next couple of weeks, or even Sept 4.
@nodejs/security-wg
@nodejs/crypto I need some help confirming impact, or lack thereof for CVE-2018-0737 on Node. It's a cache-timing attack that only impacts RSA keygen, nothing else. The fix simply switches to constant-time operations in rsa_builtin_keygen(). But, I believe that we don't expose RSA keygen anywhere or use it for anything internally. So Node wouldn't be impacted by CVE-2018-0737.
@rvagg See https://github.com/nodejs/node/issues/20090. I am working on implementing key generation following the discussion in #15116, but right now, Node.js should be unaffected by side-channel attacks against RSA key pair generation.
oh gee ... pointing me to my own issue, my memory really is getting bad. Thanks @tniessen!
[email protected] which resolved its own npm audit warnings was just releases. While they determined it not to pose a real risk I think it would be nice to include if possible.
[email protected] which resolved its own npm audit warnings was just releases. While they determined it not to pose a real risk I think it would be nice to include if possible.
@brodybits The pull request to add it was opened 40 minutes ago. I think it's going to have to wait for the next release.
[email protected] which resolved its own npm audit warnings was just releases. While they determined it not to pose a real risk I think it would be nice to include if possible.
@brodybits The pull request to add it was opened 40 minutes ago. I think it's going to have to wait for the next release.
We also have a policy of waiting two weeks before landing a new version of npm: https://github.com/nodejs/node/blob/master/doc/guides/maintaining-npm.md
Two weeks after the "latest" release has been promoted it can land on master assuming no major regressions are found.
Releases have been made: https://nodejs.org/en/blog/vulnerability/august-2018-security-releases/