Could be. https://news.ycombinator.com/item?id=19218036 Doesn’t seem super substantiated about exactly what levels they fired (hard to even say what senior means across companies). But does seem like they reduced their investment for sure.
Fun fact: If you try to do the same trick on Github Actions, it will actually run to completion without complaining and give you a heart attack, but secrets lookups will all turn out to have quietly returned the empty string. >_>
I can imagine a world where failing to access a variable discloses the existence of that secret in the first place—returning the empty string seems like a decent enough compromise.
They could just say “that secret either doesn’t exist or you don’t have access to it”, which is a pretty standard approach. It would be useful if it were raised as a flag in the UI on a forked PR’s run.
To be able to try this, you need to be able to fork the repo or submit a PR. Which means that you can look inside .github/workflows/ inside the repo. Which means that you can see YAML directives such as:
env:
FOO_TOKEN: ${{ secrets.FOO_TOKEN }}
At which point, you know the secret (probably) exists.
The basis for this OP is leaking of secrets from public repositories. So in the context of where someone could look at the configuration and try to attack, the variable existence is already disclosed.
It’s probably worth referencing https://blog.teddykatz.com/2021/03/17/github-actions-write-access.html (which I’m pretty sure was on Lobste.rs at the time) for gritty details on which secrets are available in which contexts for pull-requests:
How does GitHub Actions handle pull requests?
[…]
However, it’s important that the author of a pull request can’t access the repository’s secrets (e.g. by updating a workflow file to print out the secrets instead of running tests). To address this issue, GitHub provides two different ways to trigger Actions workflows from pull requests:
The pull_request event simulates a merge of the pull request, and triggers Actions workflows based on the configuration and code at the merge commit. This is intended for e.g. running tests, and verifying that the code would still work if the pull request was merged. However, since the code in the pull request is potentially malicious, workflows triggered by the pull_request event are run without access to the repository’s secrets.
The pull_request_target event triggers Actions workflows based on the configuration and code at the base branch of the pull request. Since the base branch is part of the base repository itself and not part of a fork, workflows triggered by pull_request_target are trusted and run with access to secrets. This is intended for e.g. adding comments and labels to new pull requests (which requires a GitHub API token).
Wasn’t Travis CI sold recently to company that fired all senior devs to cut costs?
Could be. https://news.ycombinator.com/item?id=19218036 Doesn’t seem super substantiated about exactly what levels they fired (hard to even say what senior means across companies). But does seem like they reduced their investment for sure.
Frustrating that they don’t indicate when this bug was introduced. Has it always been that way?
At least the 3rd. It was reported on the 7th and fixed on the 10th. Source: https://twitter.com/peter_szilagyi/status/1437646118700175360
Confusingly the TravisCI bulletin says it was fixed (or the fix was begun) on the 3rd. https://travis-ci.community/t/security-bulletin/12081
I will be interested to see if this is the only notice which customers receive.
On the bright side, we just got the final incentive kick to complete our migrations to GitHub Actions.
Fun fact: If you try to do the same trick on Github Actions, it will actually run to completion without complaining and give you a heart attack, but secrets lookups will all turn out to have quietly returned the empty string. >_>
I can imagine a world where failing to access a variable discloses the existence of that secret in the first place—returning the empty string seems like a decent enough compromise.
They could just say “that secret either doesn’t exist or you don’t have access to it”, which is a pretty standard approach. It would be useful if it were raised as a flag in the UI on a forked PR’s run.
To be able to try this, you need to be able to fork the repo or submit a PR. Which means that you can look inside
.github/workflows/inside the repo. Which means that you can see YAML directives such as:At which point, you know the secret (probably) exists.
You can define organization-wide secrets, some of which may be used in private repositories.
The basis for this OP is leaking of secrets from public repositories. So in the context of where someone could look at the configuration and try to attack, the variable existence is already disclosed.
It’s probably worth referencing
https://blog.teddykatz.com/2021/03/17/github-actions-write-access.html(which I’m pretty sure was on Lobste.rs at the time) for gritty details on which secrets are available in which contexts for pull-requests: