4 ms·
I think in this case they hate the fact that they cannot easily SSH into the failing VM and debug from there. Like "I have to edit my workflow, push it, wait fo
by palata 10mo ago
I think in this case they hate the fact that they cannot easily SSH into the failing VM and debug from there. Like "I have to edit my workflow, push it, wait for it to run and fail, and repeat".
- rurp 10mo agoYep, my company moved onto GH Actions a few years ago and this was probably the single biggest pain point. But also the whole system just feels awkward and annoying to work with. It feels like a classic Microsoft product that would never get traction from a standalone company but because it's part of Microsoft/GitHub and is "good enough" lots of people put up with it.
- anttiharju 10mo agoOne can get the ssh access with self-hosted runners but it is problematic because uncovering secrets becomes trivial.
- SAI_Peregrinus 10mo agoUncovering secrets is usually trivial. `printenv` in a build script does that pretty reliably.
- anttiharju 10mo agoWhat do you mean? Simple env prints get masked as *** in logs I guess one can always just echo the secret to a file and upload-artifact it
- SAI_Peregrinus 10mo agoUnless you've got something sanitizing env prints in your logs, no, they don't get masked. I've leaked secrets accidentally while debugging environment variable issues. Of course the bigger side of the issue is that anyone who can run code in the CI context can view all data in the CI context. So if an untrusted dev can write a build script that executes with secrets in the environment, they can leak those secrets. CI is RCE-as-a-service, you implicitly give permission for anyone who can edit build scripts to run arbitrary code. Like you say, they can echo the secret to a file & upload it elsewhere, and they can also use it directly from the edited build script.
- anttiharju 10mo agoSecrets that you store in github actions secrets?
- palata 10mo agoYes. I've done it. That's why there is an "approve and run" button when the PR comes from another repo. So that the maintainers can check if the PR is trying to exfiltrate secrets... or do other bad things of course. The whole point of the github action secrets is that they are accessible by the CI when needed. Which means they are accessible. It's just a convenient way to store the secret in such a way that it is not completely public. But you still have to trust github and your maintainers.
- yencabulator 10mo agoLike masking would work against anything but accidents. printenv | base64
- tracker1 10mo agoI had the weirdest thing happen a few days ago.. and only seemed to be happening in the GH runner for a PR.... somehow a function was duplicated in the action runner, and not in local or anwhere else... no idea how the corruption happened... it literally took me hours or pushing minor changes to try to correct the issue... I finally cat'd that file contents out and yep, the function was duplicated... no idea how. Had to create a new branch, copy the changes and then it worked.| Still no idea what happened or how to ever fix/prevent it again.
- nine_k 10mo agoObviously, by doing everything inside a container, where you control things. The GH action should only start the container, and pass it some env vars.
- vimda 10mo agoCircleCI had this exact feature