Determine recommendations for cooldown periods

[dave2wave]

This is mostly about actions, but the discussion should contemplate all dependency cycles.

We need a reasonable discussion of alternative plans (and not a filibuster via a wall of text.)

The following shows our current choice, but we should consider other timings.

infrastructure-actions	project repositories
none	4 days
4 days	7 days

Goals are conflicting

1. Upgrade versions quickly.
2. Upgrade versions securely.

[potiuk]

I think personally 4 is good and here is my reasoning (this is why I came up with 4 actually - it had very good reasons):

1. we need cooldown, to not be bothered ourselves by potentially malicious actions (this is for "upgrade securely").
2. the cooldown should be shorter that we recommend (or maybe in the future mandate) our PMCs to give us time to review and merge. (this is to achieve "upgrade quickly").

With those two 4 seems like a nice middle ground if we recommend our PMCs to use 7. This gives us at least 3 days (which means that there are some "work" days involved for those who do not contribute over weekend or simply get paid and work in regular hours (like infra people).

That was my justification for this repo to use 4.

[potiuk]

Also just to add why cooldown is needed I think - in our our "verify-build-actions.py" we are using docker to provide additional security isolation from potentially malicious actions. All the build steps are run in Docker, just to make sure we are not exposing anything - including no access to local /proc (used recently by LiteLLM to potentially access secrets and tokens that are not exposed to the job in GH actions).

But wiht issues like this (Docker engine high severity CVE - 2 days ago) https://thehackernews.com/2026/04/docker-cve-2026-34040-lets-attackers.html - there might be some escape hatches that malicious code might use. Cooldown is a general protection that drastically decreases risk of malicious action even getting pulled - because similarly to active malicious actors, security researchers are scanning new packages released and new actions for any malicious behaviour and will flag them relatively quickly (see https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns for more details).

[potiuk]

BTW. I am not sure what was reasoning for PMC's 7 days - because I was not here - why are we using 7 days? Anyone remembers how it was chosen?

[raboof]

I'm fine with recommending a cooldown to projects, 'a few more days than the cooldown that opens the review PR in this repo'.

I would prefer a cooldown of 0 days for dependabot PRs to trigger action reviews in this repo. I have 3 reasons for this:

1. Regardless of whether we want to mandate cooldowns for projects in the future, we don't have that requirement today, so today not having the these PRs ready for review is a hindrance for projects that don't have cooldown configured.

2. I think we should only introduce a delay into our processes if we have a strong reason for it. I do not think that strong reason exists in this case:

• I'm not convinced by the argument that this would meaningfully "cause work" for the reviewers in this repo. It "just" gives us an opportunity to review earlier. If there's a malicious release of an action, we either catch it or we don't - in each case we'll have learned something valuable.
• I'm not convinced by the argument that this would meaningfully open up this repo for attacks. The dependabot PRs don't have access to any secrets in the first place. If we merge a 'malicious' action, we're not actually running these on any workflows on the main branch, do it doesn't have a chance to infect this repo. Even if we do run those workflows on the main branch, and there is a docker or GHA infrastructure 0-day, this repo should not have access to any particularly interesting secrets in the first place - let alone expose them to 'random' allowlisted workflows.

3. The effectiveness of cooldowns depends on "someone" reviewing the actions in the cooldown period. In this repository, that someone might be us. I think that's a valuable contribution to the community at large. It might even motivate some people to do the reviews: there's actually a chance you might find something. And if you don't want that? Then you're still free to wait a few days before reviewing.

I don't think the "Upgrade versions quickly" and "Upgrade versions securely" goals have to be in conflict at least here, as we want to upgrade versions quickly in this repo, and care more about upgrading versions securely in project repo's.

[potiuk]

I am fine with no cooldown if you are really strongly convinced 0 day is fine and you are ok with accepting the risks @raboof. I do not want to fight for it - we have different opinions here, which happens but if this is going to be a reason for "fight" - I am happy to not have it at all, my level of wanting cooldown is about 3 in 10 point scale (for reasons I explained above). But if your confidence is higher than that on 10 point scale, I am happy to let my 3 points go