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
We are already using a `$CARGO` environment variable, which is
mainly for convenient expansion by the shell, but `cargo` (and
commands like `cross` with the same interface) pass it on to build
scripts, which may use it (and if or how they do may in principle
vary by feature or target). But the sitation with `$TARGET` is
analogous--it would also make commands more readable, and it is
also passed down to scripts by `cargo`.
So this adds `$TARGET`.
Doing this serves another purpose, which is to make it easier to
reason about the semantics of the commands the shell is running.
Using `${{ }}` interpolation should not be a security risk here,
since all values are trusted. But injecting characters such as `'`
could still happen by accident. Often it may not be justified,
outside of reusable workflows or those running on events with
elevated security risks, to route them through environment
variables to ensure their contents are not interpreted specially
by the shell. However, with the addition of `$TARGET`, it seems
that most of that has already been done, such that clarity is
overall improved rather than worsened by going the rest of the way.
So this does that too, adding other environment variables in the
narrowest scope that is broad enough to avoid duplication. Now all
`${{ }}` interpolations are outside of script code. Note that
these changes only apply to the release workflow and may not
necessarily be justified in other workflows.
0 commit comments