Regular schedule for Security releases?

[mhdawson]

I think @sam-github suggested this in an issue, but I think it would be good to have a specific issue to discuss.

I'm +1. It's understood that we will still have to have some emergency security releases based on disclosed vulnerabilities or OpenSSL updates but it seems like planning for a regular cadence would be good both for the project and the consumers or Node.js.

@nodejs/security-wg

[Trott]

Seems sensible to me. Two thoughts:

• Maybe we can automate that addition and removal of the banner announcing security release availability to the website.

• Maybe we should try to align our schedule with some de facto industry standard like Patch Tuesday.

[mcollina]

What would be a good schedule? How about monthly if there is anything to release?

[mhdawson]

In terms of schedule, I think it depends on how much we have to get in. I think we want the smallest number (assuming less release is less overall work) that gets fixes out in a reasonable timeframe. I was thinking maybe every 2 months?

[sam-github]

Sec releases take a reasonable amount of work, and block CI for days, monthly seems too fast to me. We seem to be doing about 4 a year, maybe keeping to that pace, but with a more predictable cadence, would work.

[Trott]

Sec releases take a reasonable amount of work, and block CI for days

Fixing (or at least mitigating) both of those problems would seem to be decent strategic initiatives, if we have someone on TSC willing to do the work and championing them. (I might be able to take on the CI one at some point, but right now I'm awaiting a decision on my request to re-join TSC.)

[ljharb]

I’m a bit confused; when would you have a security fix, but not release it more-or-less immediately, or at the soonest opportunity?

[sam-github]

Lots of security issues are things that have existed since the early days of node, can't really be prevented (like a DoS), but the sensitivity to them can be adjusted. Take the last round of security fixes. IMO, they could have been done mostly (entirely?) as open PRs in node, not in private. Sure, people could be watching our PRs, and see the DoS opportunity and exploit... but none of them allowed node servers to be smashed, and the fix just adjusts a knob, making the DoS linerally less effective. Anyone who has heard of slowloris and wanted to play around with node could already have found them, and with a large enough bot farm, been exploiting them. Another category of recent vulns that required web servers to use specific coding patterns for the issue to be exploited. Its hard to argue about how common the patterns are, as they do exist, but most most node servers aren't affected.

A heartbleed level attack would be fixed ASAP. But those aren't the common security issues we release in security updates, its just bugs/features, that have some credible possibility of security implications, to someone, somewhere, so we have to advertise them via CVE, just in case.

[ljharb]

Sure, it makes sense that not everything is a "stop the world, release now" situation - but presumably a normal release happens pretty regularly whenever there's anything landed and unreleased, so any non-urgent security fixes would just get naturally shipped with those, no?

[sam-github]

We don't mix security and non-security updates in a single release. Not as far as I know. I'm not sure of the history of why this is, but I assume its to make updates as safe as possible for people who don't intend to make updates to their deployed-and-working apps unless they have to. Also, security updates get released simultaneously across all release lines, so that old release lines aren't "vulnerable" while new lines are protected. This is unlike normal features and bugs, which bake a while in current before they are considered stable enough to be backported to LTS.

@MylesBorins @rvagg perhaps can comment on this.

[mhdawson]

You are correct that we specifically ensure that in security releases the only changes are for the security-related fixes. And we do it that way as you said to make updates as safe as possible for people who don't intend to make updates to their deployed-and-working apps unless they have to.

[MylesBorins]

I have very mixed feelings on this

If we were to do it I think a cadence that would make sense would be quarterly. With that being said the timing that we have might be a bit rigid... we don't know when very serious vulnerabilities come in... and while we do end up having a backlog of "non critical" sercurity bugs I'm unsure that we want to be giving up 1 in 3 LTS releases to security releases.

Alternatively, perhaps we can focus on improving our ability to test and prepare security releases with a smaller sub-set of CI... that seems to be the bigger issue than cadence to me. Please correct me if I am wrong

[mcollina]

We have a concept of a "missed target" in HackerOne. I have not found this defined anywhere in our policies, but maybe I missed it. Have we defined a max time between a vulnerability is sent and a fix is received?

[lirantal]

It's a HackerOne setting that applies.

Defaults (and maximum) that apply to projects are:

• Time to first response: 5 days
• Time to triage: 10 days
• Time to resolution: 40 days

[mcollina]

Basically with a quarterly schedule we are almost 100% certain to go over that maximum time to resolution.