So basically my question is, is it always OK to resolve environment (or other context) variables at the “workflow level” in a ‘run’ statement using expressions like this? Are there any gotchyas/things to watch out for?

The main thing to keep in mind is that ${{ ... }} is Actions syntax: It has absolutely nothing to do with the shell, and the shell never knows about it. It’s templating, basically: The Actions runner substitutes the ${{ ... }} with whatever the result of the expression between the double curly brackets is to make a script file. That script file is then passed to the shell for the run step. So if the result of the expression contains any characters the shell treats specially (e.g. spaces, quotes, semicolons, …), you may get odd to dangerous results.

When you use environment variables with shell syntax you get whatever processing/escaping your shell of choice does.

Of course you need to be careful with untrusted input either way, and validate or escape it as appropriate.

Ok, I understood that the expressions are evaluated at the “Actions level”, being passed to the shell with all substitutions already performed, but thanks for the notes on what to watch for when approaching variables this way as I do see how it could be a bit easier to miss special characters being passed in without the proper escapes.

I’m also just curious about the history of this use given all of the instances of guides implying variable substitution must be applied by the shell in a run action, whereas it sounds like, at least today, its more of a recommendation than a requirement.

Wasn’t sure if it used to be the only option, or is just the way that most prefer, and therefore is spoke about in a way as if it was the method.

Ah, thanks for the clarification.

Perhaps I was exaggerating how strict the references I’m referring to sounded, but that was still my overall initial impression.

With the “luxury” of being someone just getting started with this, I will be trying to use the env context as much as possible, so that’s nice to hear the logs will be a little more helpful in that case. Though, I’m certainly a bit irked by the fact you can’t set variables in the env path using other env context variables, and instead need to do so using the shell. Hopefully in the the workflow script parser becomes powerful enough to allow for that 😅.

Of course you need to be careful with untrusted input either way, and validate or escape it as appropriate.

One addition: The article linked below is a good description of what can go wrong with untrusted input. And yes, it’s easier to do wrong with templating. 😅

  <a href="https://securitylab.github.com/research/github-actions-untrusted-input/" target="_blank" rel="noopener" title="12:00AM - 28 January 2021">GitHub Security Lab – 28 Jan 21</a>

Keeping your GitHub Actions and workflows secure Part 2: Untrusted input

In this article, we’ll discuss possible avenues of abuse that may result in code and command injection in otherwise seemingly secure workflows. Our examples are based on real-world GitHub workflow implementation vulnerabilities the GitHub Security...

I appreciate the reference.

This does explain why some just avoid using the GitHub expressions when writing run sections altogether. Otherwise I will need to pay close attention to which context variables are used, and where, with what events I trigger a given workflow, and who exactly is interacting with the repository.

I’ll definitely be more careful and not just blindly use ${{ X }} all over the place.