I'd like to establish a criterion for accepting or rejecting tool support that requires them not to use obviously dangerous workflows.
I don’t think it’s necessary to satisfy all of zizmor’s lint rules, but if triggers like https://docs.zizmor.sh/audits/#dangerous-triggers or comments-related are existed or added later (i.e., manual reviews when adding tools don’t work), I’d like to be able to reject the addition of tool support or version updates.
Related: #488
Unlike that case, since the maintainer lacks awareness of GHA security but has no malicious intent, I don’t think this situation is as difficult as that one.
However, we should avoid using support for this action as an excuse to submit reports that have nothing to do with actual vulnerabilities like rust-lang/rust#154414, thus burdening the maintainer.
cc @jayvdb
I'd like to establish a criterion for accepting or rejecting tool support that requires them not to use obviously dangerous workflows.
I don’t think it’s necessary to satisfy all of zizmor’s lint rules, but if triggers like https://docs.zizmor.sh/audits/#dangerous-triggers or comments-related are existed or added later (i.e., manual reviews when adding tools don’t work), I’d like to be able to reject the addition of tool support or version updates.
Related: #488
Unlike that case, since the maintainer lacks awareness of GHA security but has no malicious intent, I don’t think this situation is as difficult as that one.
However, we should avoid using support for this action as an excuse to submit reports that have nothing to do with actual vulnerabilities like rust-lang/rust#154414, thus burdening the maintainer.
cc @jayvdb