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

[dave2wave]

In dependabot.yml there are two sets of checks.

1. Is the GitHub Actions where we are in consensus that we should switch to a 0 day cooldown.
2. Is for uv. I think that these should have a cooldown. Is 4 days still reasonable?

[potiuk]

One more thing to add : #703 - I just added a proposal to add hash commits for all actions - including github/* and actions/*.

And while ASF has the polic
y of not having to pin those, I am personally much in favour of using hash commit for every action - especially that it is almost 0 overhead:

a) dependabot will automatically upgrade those
b) we are protected even if particular single GH action is breached - yes it's unlikely, but also it's one of the highest-value-target actionas that you can imagine, and having extra protection against those - especially that it does not cost pretty much anything - is a good idea.

In this context we have few good things:

• dependabot will automatically upgrade nice those actions as well
• cooldoown (even 1 day) on those will protect us against github action single-action breaches
• we will also be able to see if there are any breaking changes - with dependabot PRs.

This is the policy we use in Airflow (all actions pinned - no-exception) and I think it's a good idea for us - especially as we found out that we have some personal access token availlable to some of those actions - tokens that would allow admin access and push to the repo directly, bypassing the branch protection.

[raboof]

In dependabot.yml there are two sets of checks.

1. Is the GitHub Actions where we are in _consensus_ that we should switch to a 0 day cooldown.

2. Is for `uv`. I think that these should have a cooldown. Is 4 days still reasonable?

sounds good to me!

[raboof]

One more thing to add : #703 - I just added a proposal to add hash commits for all actions

(I don't understand why this post is in this thread tbh)

[potiuk]

(I don't understand why this post is in this thread tbh)

Just to stress that in case we set dependabot cooldown for those - it will apply also to regular actions this workflow uses -> this is the relation. So the action we use here for regular things will get the cooldown applied. Just as a note - that cooldown (unless we apply it selectively) - will also apply to those actions - so we might choose different cooldown for "dummy" workflow and different for all others for example.

Of course we are using only "github/" and "actions/" for now - so it's "reasonably" safe, but well, so was trivy. So since we are agreening a general rule - I think we should just to consider having different cooldow for the actions that we actually run as part of the workflow, not the reviewed ones.

While yes 0 cooldown, for reviewed ones - is a choice we made, I think for those actions that are actually "used" by us here, maybe we should apply the same cooldown we recomment others?

[potiuk]

Something like that ?

GH Actions:

infrastructure-actions (review)	infrastructure-actions (use)	project repositories (use)
none	7 days	7 days

UV:

infrastructure-actions (use)	project repositories (use)
7 days	7 days

(note - we could put also 4 or 7 there)