Rendered at 20:40:00 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
h1fra 8 minutes ago [-]
the title is incorrect; it's not a github error but php composer's github action. cc @dang before people freak out
Normal_gaussian 1 hours ago [-]
GHA have always been a PITA for any serious DevOps; it's quite clear they were designed to integrate in 7 lines of code and then tell everyone who complains that they're doing it wrong.
This does not surprise me.
freedomben 35 minutes ago [-]
It is a PITA, but that can be significantly improved IMHO if you just write shell script wrappers for your tasks. Not only does it make it easier to run CI locally, but it also makes it so much easier to move platforms in the future.
When the GH action YAML is just invoking shell scripts, I find it quite pleasant to use
datadrivenangel 25 minutes ago [-]
You've perfectly described how microsoft operates and how github actions is apparently based on AzureDevOps pipelines.
youre-wrong3 14 minutes ago [-]
No. GHA has always been trash before MS got to it. A lot of GHA influenced ADO.
damienwebdev 9 hours ago [-]
I was the reporter on this one. If you have Github Actions in your organization, disable them immediately if you're unsure which version of composer your Github Actions run.
ammar2 44 minutes ago [-]
Could you elaborate on this bit on why Github's secret masking doesn't work here:
> GitHub Actions' built-in secret masker matches registered values as exact substrings. When the exception message is rendered by Symfony Console it may wrap, embed in In BaseIO.php line N: framing, or interleave with ANSI control sequences. So the masker does not redact, and the plaintext token reaches the log.
What does this log rendering look like such that the token from that code snippet becomes interleaved enough to not be a substring match?
I'm not familiar with composer/Symfony but I would expect something like:
Line 34: Foo bar
Line 34: <red>Foo bar</red>
jacobrussell 30 minutes ago [-]
From what I can tell Symfony wraps these errors in a styled error block so it messes with GitHub's masking. For example, newlines breaking up the token are apparently enough to trick the masker since it's not a substring anymore.
For your example:
Line 34: <red>ghs_fdsafdsarewqfdsa...</red>
Is probably long enough in most cases to break to a new line.
Also, those blocks get "interleaved" like this:
<red>ghs_fdsafdsarewqfdsafdsa</red>
<red>fdsardsardsafdsafs......</red>
So there are now </red>'s within the token, also breaking the substring matching.
This is kind of eye-opening for me -- I have never thought about how styled output like this could cause logging leakages.
ammar2 24 minutes ago [-]
Aah, the newlines were the thing I was missing. That makes sense then.
semi-extrinsic 49 minutes ago [-]
Not immediately clear to me, is this limited to ghu_xxx type OAUTH tokens? And it's only relevant for PHP projects that use composer in GHA?
jacobrussell 39 minutes ago [-]
That's my understanding. This seems to only effect PHP projects that use Composer in GitHub actions. Examples being usage of shivammathur/setup-php and or php-actions/composer.
euph0ria 34 minutes ago [-]
What is the security implication for private repos?
This does not surprise me.
When the GH action YAML is just invoking shell scripts, I find it quite pleasant to use
> GitHub Actions' built-in secret masker matches registered values as exact substrings. When the exception message is rendered by Symfony Console it may wrap, embed in In BaseIO.php line N: framing, or interleave with ANSI control sequences. So the masker does not redact, and the plaintext token reaches the log.
What does this log rendering look like such that the token from that code snippet becomes interleaved enough to not be a substring match?
I'm not familiar with composer/Symfony but I would expect something like:
For your example:
Line 34: <red>ghs_fdsafdsarewqfdsa...</red>
Is probably long enough in most cases to break to a new line.
Also, those blocks get "interleaved" like this:
<red>ghs_fdsafdsarewqfdsafdsa</red>
<red>fdsardsardsafdsafs......</red>
So there are now </red>'s within the token, also breaking the substring matching.
This is kind of eye-opening for me -- I have never thought about how styled output like this could cause logging leakages.
It's not an issue in GHA itself, this time. But if you are a composer user in GH, you should definitely be warned (and worried).