Add option to prevent running of non-frozen hooks

[StevenMaude]

Background

Supply chain issues, just as in #1895, are a considerable worry.

The (very good!) documentation states on rev:

Use a tag or commit SHA for repeatable results.

Commit hashes should be reasonably immutable enough for now¹. But tags may be mutable. This requires both:

• the repository host service to support immutable tags
• a repository owner to enable immutable tags²

It would be helpful to prevent running of non-frozen hooks.

What's the risk that this feature would guard against?

1. Someone legitimately configures a repository with hooks pointing to other repositories configured with rev as tags.
2. An attacker compromises one of those repositories.
3. The tag has not been configured to be immutable.
4. The attacker creates a malicious commit, and modifies mutable tags to point to the new commit.
5. Someone setting up a new development environment may pull in the malicious hooks.

As one example, the recent attack on Trivy switched existing tags to point to malicious commits. This wasn't an attack on hooks, but it could work the same way.

Suggestion

It would be useful to be able to enforce somewhere that rev for all hooks are pinned to something that's reasonably immutable.

• This might be via a runtime validation, to prevent hooks from running if they are not pinned to commits.
• It might also be via a built-in hook, to check for, and block non-immutable rev from getting into the configuration.

It is possible for us to write hooks or CI checks ourselves to do this per project. But it would be useful as a first-class feature, making it simpler to enforce as policy.

What I looked at already

I looked through the documentation and cannot find an existing way to do this. I did see auto-update --check --freeze, but that doesn't quite solve the problem: you may want to enforce frozen commits without updating them.

Footnotes

1. Assuming collision attacks on them aren't an issue. ↩

2. GitHub does have immutable releases. ↩