Recursion through reusable workflows + composite actions.

[jcgruenhage]

Is recursion through multiple levels of reusable workflows and composite actions something that zizmor strives to do?

Consider the following scenario:

Zizmor has unpinned-uses configured like this:

rules:
  unpinned-uses:
    config:
      policies:
        "*": hash-pin

The repo contains a workflow that is run for every PR. It includes a reusable workflow from another repo. zizmor will ensure this reference is pinned. So far, so good.

The reusable workflow itself calls actions - will these also have "*": hash-pin enforced? Now the called action is a composite action, will that internally also have "*": hash-pin enforced?

I think at the moment this is not supported. At least in my testing locally, I had a workflow that pinned tj-actions/pg-dump to c826d55715b153f5572006e464e69b2bf0422fea which internally uses tj-actions/install-postgres pinned to v3, and zizmor running with --persona pedantic did not catch this.

[jcgruenhage]

Sidenote: The graph that will be a side-product of recursing through the dependencies via reusable workflows + composite actions would be really useful for understanding the supply chain behind a github actions workflow run.

[woodruffw]

Is recursion through multiple levels of reusable workflows and composite actions something that zizmor strives to do?

Long term, yes -- I've thought about enabling a feature like that, but two design points that I need to think through:

1. zizmor is offline by default, and all of the features (except for explicitly online ones) treat offline operation as a first-class citizen. This would be a first-class online mode, which is fine, but requires me to think more about I want to communicate the difference in behavior/results in different modes.
2. Architecturally, this would be nontrivial to add -- at the moment zizmor has a "collect and process" architecture that assumes that inputs are resolved up-front, but this would require the to-be-audited set to be updated on the fly. Switching to a graph/DFS would also have output implications, e.g. the current SARIF and "plain" outputs will probably less directly intelligible when deeply nested across multiple repos.

TL;DR: This is something I want to do, but it's not a short-term priority 🙂 -- my short-term priorities are

• Getting the set of audits into a "stable" state (where relative few new ones need to be added)
• Burning down some technical debt in zizmor's design + test layouts
• Implementing a LSP server/client so that people can integrate zizmor in their IDEs

[jcgruenhage]

This sounds very reasonable, and about in line with what I expected. Thanks for the explanation!

[woodruffw]

No problem, I appreciate you opening this! If you don't mind, I'll convert this into an issue -- it's definitely something I want to do, but it probably won't happen until a v2 🙂

[woodruffw]

Tracking with #678