Getting a hold of someone's secrets is not possible just by doing a pull request. It's really only about resource usage, at least when the runners in question provide sufficient isolation (true at least for the Github-hosted ones, or we're all in big trouble).
Unfortunately, using self-hosted runners to provide additional capabilities not supported by Github-hosted ones is basically impossible (for public repos at least) as you can't restrict a runner to an organization or project. Set up a bare-metal runner and it will receive jobs from random forks.
> Getting a hold of someone's secrets is not possible just by doing a pull request
Only if you've configured the actions correctly. I would bet that there is a high number of repositories on both GitLab and GitHub with misconfigured CI pipelines where someone can submit a PR with `env | curl` to grab any secrets defined as environment variables.
No, GitLab does not allow marking variables as secrets. They allow "masking" env variables, subject to a bunch of caveats, like your secrets not being multiple lines (e.g. a private key cannot be masked). Even then, the masking is just about log output -- it doesn't prevent a `env | curl` type situation. [0]
The correct mitigation is to ensure that any "secret" variables are marked as "protected" so they can only run on protected branches that are limited to pushes by maintainers. And you'll still need to make sure the masking works in the logs.
They do support integrating with Vault to access secrets in a CI job, but you need to pay them to use that feature. [1]
For GitLab if you don't have at least developer access to the repository (as in you are sending a MR from a fork) that will run in the context of your user, so you don't have access to any secrets configured upstream, etc.
If you have access to a repository you can customize the script to do whatever you want, but there will always be a trace tracking it back to you.
There is a discussion about ultimate security (access only when asked) Vs the convenience of self-service.
You can still avoid that by having people use a fork model, or triggering CD from an external project with tight access.
Putting a burocratic process between ICs will only limit their throughput as in Jenkins paradigm.
The better advice is don't hire people you can't trust
Add one extra command ;-) These can be innocuous if buried in something like unit tests of configs or network behavior, or in a big pr:
logs: `env | base64`
network: `env | gzip | curl`
It should be easy to set most workflows to run sandboxed with almost no capabilities - no secrets access, safelisted network access, safelisted package manager accesses for top 10 langs, etc - so that testing someone's PR isn't scary, and runtime violations make loud noises. The whole 'just disable actions on fork PRs' thing is a great default, but ultimately a figleaf as it's not hard to get someone to run an action.
The only thing I know about this is what I learned from the OP reporting the vulnerability. Maybe I was mistaken the request was HTTP? Anyway, rest applies, assuming the article is correct in describing the nature of the vulnerability.
Anyway, if this is how TextEdit got around macos access controls related to network activity, I wonder if this is a route for other apps, including malicious ones, to get around it too?
> After digging into OSX internals, I came across the AutoMount feature that lets file:/// urls make remote requests. AutoFS is a program on OSX that uses the kernel to make a mounting request to a drive. Automount can also make remote requests to an external drive. Doing 'ls /net/EXAMPLE.com' forces OSX send a remote request to EXAMPLE.com
> While they did a good job blocking TextEdit from making external requests, this was the one thing they forgot when they allowed file:/// scheme, on OSX file:///net/11.22.33.44/a.css connects to 11.22.33.44.
Seems reasonable to me: this way, you don't have to duplicate the BOM stripping in the decoders of every single format you want to support.
It's also more general as there are other commonly-needed transformations that have an even weaker case for explicit support in the CSV library (charset conversion, dropping other bogus bytes, ...).
No. QUIC is a transport protocol. Its purpose is roughly equivalent to TCP: provide a reliable byte stream transport over an unreliable datagram service (IP, though QUIC prepends a small UDP header mostly for compatibility with existing infrastructure).
You might be thinking of the HTTP server push functionality. That was introduced with HTTP/2 and has been deployed for years already over TCP transports (i.e. totally unrelated to QUIC).
Due to how advertising networks work, I'd be surprised if anyone used server push in the way you fear.
Not libc. The stack probe was inserted by the compiler when compiling the vDSO (part of the kernel, but mapped into user processes) with certain ricer^Whardening flags enabled.
Unfortunately, using self-hosted runners to provide additional capabilities not supported by Github-hosted ones is basically impossible (for public repos at least) as you can't restrict a runner to an organization or project. Set up a bare-metal runner and it will receive jobs from random forks.