Feature: Require or recommend the `timeout-minutes` property for all jobs

[johnbillion]

Pre-submission checks

• I am not reporting a bug (crash, false positive/negative, etc). These must be filed via the bug report template.
• I have looked through the open issues for a duplicate request.

What's the problem this feature will solve?

The timeout-minutes property can be used to prevent run-away jobs from consuming all your allowed GitHub Actions runner minutes. The default value is 360 minutes (6 hours).

Examples include scripts that accidentally hang or go into a loop, package managers which slow to a crawl when the registry is responding slowly, compilers that get stuck, or really anything else that can unexpectedly slow but not be constrained by its own timeout.

I use this property on all jobs in all my workflows.

Describe the solution you'd like

I would like Zizmor to enforce or recommend the use of a timeout-minutes property on all jobs. This property is not strictly related to security, but I think it's such a useful configuration that it could be part of the "pedantic" or "auditor" persona.

At a stretch, you could suggest that a vulnerability in a workflow could allow an attacker to consume all your GitHub Actions minutes, and this would protect against that, but honestly it's more likely that npm install hangs and eats all your allowance.

Additional context

Jobs which call a reusable workflow (with uses) do not support timeout-minutes. The property needs to be defined in the jobs within the reusable workflow that it calls.

[woodruffw]

Thanks @johnbillion! Yeah, I agree this would be good as a "pedantic" finding.

(I agree with your comments about security relevance -- this is funny in that it cuts both ways, i.e. an attacker could waste resources without timeout-minutes, or they could induce an availability risk with timeout-minutes. Which one is more important probably ends up being context- and trigger-sensitive.)

[EmmanuelBerkowicz]

Hey @woodruffw , @johnbillion,
I'd like to work on this issue.
I'm relatively new to contributing to Python projects but have experience with CI/CD workflows and GitHub Actions.
Could you point me to any existing checks that would be good examples to follow for implementing this feature?

[woodruffw]

Hi @EmmanuelBerkowicz, thanks for offering your time.

This is a Rust project, not a Python project, just so you know 😉

Could you point me to any existing checks that would be good examples to follow for implementing this feature?

Any of the pre-existing audits that use audit_normal_job would probably be a pretty good reference point -- see UnpinnedImages for example:

zizmor/crates/zizmor/src/audit/unpinned_images.rs

Line 49 in 22958cb

fn audit_normal_job<'doc>(

(This audit should be simpler than most -- it should be mostly a matter of checking timeout_minutes on each job and step, and raising a finding if any is missing or if the step(s) aren't transitively covered by the job.)

The docs here should also help a bit, although they're also a bit stale: https://docs.zizmor.sh/development/#adding-or-modifying-an-audit

[EmmanuelBerkowicz]

@woodruffw ,
I knew that.... I am just Rust-y on my git commenting....
Still keen to contribute! If the timeline allows me to work on this on the weekend :)

[woodruffw]

Yeah, that's no problem at all. Let me know if you have any questions about the codebase!

[EmmanuelBerkowicz]

Hey @woodruffw ,
Sorry for getting onto this so late. Work and Study pilled on me together.
I'm setting this up, but I can't install homebrew because I am on windows.
Do you know of a workaround for this?
Thanks!

[woodruffw]

No problem.

You shouldn't need Homebrew to develop this project, all you need is a Rust toolchain for most changes.

You can follow the instructions for Windows here: https://www.rust-lang.org/

[EmmanuelBerkowicz]

Thanks for the quick answer mate!
I'll look over this during the week and give it another crack soon :)