You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[NEXT-SECURITY-RELEASE] Heads up on upcoming Node.js security release 2025/12/15 #4200
There has been an ask if we can partially relax the controls on the public Jenkins CI in the meantime to allow CI on non-security related PRs.
Specifically, the ask/proposal was:
Allow TSC members to start CI runs.
Allow the github-bot to start CI runs.
To recap, we lock down the CI primarily to avoid any potential leakage of the security patches based on the CI runs.
For the first point, TSC members currently do not have permission to start CI during a CI lockdown to avoid tying up the CI and give priority to the people preparing the security release. TSC members already have full access to the Hackerone reports and the private repo hosting the proposed patches, so there is no additional leakage risk here.
For the github-bot, usually it is considered a collaborator (it is a member). Access to the bot account is @nodejs/build-infra, who should already have full access to Jenkins. So I think it should be okay to give the bot permission to start CI runs.
If the above is done, then for the next few weeks CI can be run:
by the request-ci label in GitHub
by a TSC member
Since general read access would still be restricted, it would be up to TSC members to relay any information from the CI runs (i.e. failures).
@nodejs/build If I don't hear any objections/concerns with the plan I'll go ahead either Thursday or Friday.
Reacted by Joyee Cheung, Rafael Gonzaga, Marco Ippolito and Michaël Zasso
Just an observer's perspective, but might it be better to keep the request-ci workflow disabled, and have manual runs only?
I'm just thinking that releasing a couple of dozen PRs into the CI pipeline simultaneously (almost all of which are inevitably going to need resuming for flakes at least once) is going to put a lot of burden on TSC members, particularly given the time of year. If kept manual-only, then any members who wish to volunteer themselves to "take ownership" of a particular PR's CI run can do so, without wasting runner time on jobs that no-one ends up following up and need to be fully re-run at a later date.
I've relaxed the controls as per the proposal in #4200 (comment):
Just an observer's perspective, but might it be better to keep the request-ci workflow disabled, and have manual runs only?
The change should allow the bot to be able to start CI runs. I'm going to defer whether to reenable the workflow to other @nodejs/tsc members who are likely to be active over the next few weeks.
Just an observer's perspective, but might it be better to keep the request-ci workflow disabled, and have manual runs only?
I think the concern is more about read access than write access (or access to start a CI run), because read access can potentially leak information about the vulnerabilities being tested in the same CI infra (that persists information and cache over runs).
Jenkins doesn't seem to allow write access without read access, so that configuration might not be possible; but also, since the visibility of the the CI results need to be restricted to those who also can access the vulnerabilities, even if that configuration is possible it probably is not too different in terms of workload - even if those who don't have access to the vulnerabilities can restart CI themselves, they still need to ping those who do to see whether the last CI run succeeds to decide whether a re-run is needed or whether a PR is ready to land, or to understand how it fails if the failure is real.
Activity
richardlau commentedon Dec 8, 2025
@marco-ippolito From when do you need the CI locked down from?
marco-ippolito commentedon Dec 8, 2025
I think Wednesday, since are releasing on Monday and its 4 linesGiven we might have to delay due to a pending fix, I'd say Thursday 11th
richardlau commentedon Dec 10, 2025
Okay, I'll the CI lock down from tomorrow.
richardlau commentedon Dec 11, 2025
CI is now locked down.
richardlau commentedon Dec 17, 2025
The security release has been delayed until 7 January 2026.
There has been an ask if we can partially relax the controls on the public Jenkins CI in the meantime to allow CI on non-security related PRs.
Specifically, the ask/proposal was:
To recap, we lock down the CI primarily to avoid any potential leakage of the security patches based on the CI runs.
For the first point, TSC members currently do not have permission to start CI during a CI lockdown to avoid tying up the CI and give priority to the people preparing the security release. TSC members already have full access to the Hackerone reports and the private repo hosting the proposed patches, so there is no additional leakage risk here.
For the github-bot, usually it is considered a collaborator (it is a member). Access to the bot account is @nodejs/build-infra, who should already have full access to Jenkins. So I think it should be okay to give the bot permission to start CI runs.
If the above is done, then for the next few weeks CI can be run:
request-cilabel in GitHubSince general read access would still be restricted, it would be up to TSC members to relay any information from the CI runs (i.e. failures).
@nodejs/build If I don't hear any objections/concerns with the plan I'll go ahead either Thursday or Friday.
Renegade334 commentedon Dec 19, 2025
Just an observer's perspective, but might it be better to keep the request-ci workflow disabled, and have manual runs only?
I'm just thinking that releasing a couple of dozen PRs into the CI pipeline simultaneously (almost all of which are inevitably going to need resuming for flakes at least once) is going to put a lot of burden on TSC members, particularly given the time of year. If kept manual-only, then any members who wish to volunteer themselves to "take ownership" of a particular PR's CI run can do so, without wasting runner time on jobs that no-one ends up following up and need to be fully re-run at a later date.
richardlau commentedon Dec 19, 2025
I've relaxed the controls as per the proposal in #4200 (comment):
The change should allow the bot to be able to start CI runs. I'm going to defer whether to reenable the workflow to other @nodejs/tsc members who are likely to be active over the next few weeks.
joyeecheung commentedon Dec 19, 2025
I think the concern is more about read access than write access (or access to start a CI run), because read access can potentially leak information about the vulnerabilities being tested in the same CI infra (that persists information and cache over runs).
Jenkins doesn't seem to allow write access without read access, so that configuration might not be possible; but also, since the visibility of the the CI results need to be restricted to those who also can access the vulnerabilities, even if that configuration is possible it probably is not too different in terms of workload - even if those who don't have access to the vulnerabilities can restart CI themselves, they still need to ping those who do to see whether the last CI run succeeds to decide whether a re-run is needed or whether a PR is ready to land, or to understand how it fails if the failure is real.
RafaelGSS commentedon Jan 13, 2026
Security release is now available.
marco-ippolito commentedon Jan 13, 2026
Security release is out
richardlau commentedon Jan 13, 2026
CI has now been unlocked.