News for hackers. Stuff that matters.
Re:We Executed a Critical Supply Chain Attack on PyTorch by jackwilsdon on Sunday January 14, 2024 @04:19PM (#38994540)
GitHub themselves don't seem to provide any mechanism to make runners ephemeral. It looks like all they allow you to do is flag a runner as ephemeral, meaning it will be de-registered once a job is completed - you need to write your own tooling to wipe it yourself (either via starting a whole new runner in a new environment and registering that or wiping the existing runner and re-registering it).

https://docs.github.com/en/actions/hosting-your-own-runners/...

Re:We Executed a Critical Supply Chain Attack on PyTorch by gz5 on Sunday January 14, 2024 @05:34PM (#38995126)
there are 3rd party foss options (1):

1. ephemeral + zero implicit trust (2) https://blog.openziti.io/my-intern-assignment-call-a-dark-we...

2. zero implicit trust: https://github.com/openziti/ziti-webhook-action

(1) disclosure, maintainer (2) zero implicit trust in this case = no open inbound ports on underlay; need to access via app-specific overlay which requires strong identity, authN, authZ

Re:We Executed a Critical Supply Chain Attack on PyTorch by crohr on Monday January 15, 2024 @03:07AM (#38998456)
I've just made runs-on [1] for that purpose: self-hosted, ephemeral runners for GitHub Action workflows. Long-running self-hosted runners are simply too risky if your project is public.

[1]: https://runs-on.com