You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I agree that workflow inputs can be untrusted since an untrusted value may be derived from other context properties.
It depends on how the input is used in caller site. For example, using foo in call-workflow1 call, but it is not untrusted in call-workflow2 call.
Caller:
jobs:
call-workflow1:
uses: org/repo/.github/workflows/reusable-workflow.yml@mainwith:
# The input `foo` is untrustedfoo: ${{ github.event.issue.body }}call-workflow2:
uses: org/repo/.github/workflows/reusable-workflow.yml@mainwith:
# The input `foo` is not untrustedfoo: test
Callee:
on:
workflow_call:
inputs:
foo:
type: stringjobs:
test:
runs-on: ubuntu-lateststeps:
# This `inputs.foo` access may or may not be untrusted
- run: echo ${{ inputs.foo }}
The option is always reporting that the input is untrusted. This means it would cause so many false-positives since actionlint reports an error whenever any input is used in run:. I agree that it's safer, but it would annoy users.
Action lint already does this for the github context, could/should it consider workflow input fields as "untrusted" as well? I don't mind making a PR for this as well if needed.
#19
The text was updated successfully, but these errors were encountered: