31–40 of 74 posts
Works great with commit hooks :P
Also working on a feature to recursively scan remote dependencies for lack of pins, although that doesn’t allow for fixing, only detection.
Very much alpha, but it works.
This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process. You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the…
The problem with these "microprograms" have always been that once you delegate so much, once you are willing to put in that little effort. You can't guarantee anything.
If you are willing to pull in a third party dependency to run git diff, you will never research which permissions it needs. Doing that research would be more difficult than writing the program yourself.
Been tracking this project for a while https://github.com/chains-project/ghasum . It creates a verifiable checksum manifest for all actions - still in development but looks very promising. Will be a good compliment to Github's Immutable Actions when they arrive.
This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process. You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the…
Earlier quoted context omitted.
How do apt, dnf, and apk prevent malicious software from getting into repositories?
never update
After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version https://github.com/santrancisco/pmw It has a few "features" which allowed me to go through a repository quickly: - It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code…
This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process. You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the…
Also the secrets are accessible only when a workflow is invoked from trusted trigger ie. not from a forked repo. Not sure what else can be done here to protect against compromised 3rd party action.
This has some good advice, but I can't help but notice that none of this solves a core problem with the tj-actions/changed-files issue: The workflow had the CAP_SYS_PTRACE capability when it didn't need it, and it used that permission to steal secrets from the runner process. You don't need to audit every line of code in your dependencies and their subdependencies if your dependencies are restricted to only doing the…
Likewise, similar to modern smart phones asking if they should remove excess unused privs granted to certain apps, GHAs should likewise detect these super common overprovisionings and make it easy for maintainers to flip those configs, e.g., "yes" button
After tj-actions hack, I put together a little tool to go through all of github actions in repository to replace them with commit hash of the version https://github.com/santrancisco/pmw It has a few "features" which allowed me to go through a repository quickly: - It prompts user and recommend the hash, it also provides user the url to the current tag/action to double check the hash value matches and review the code…
renovate can be configured to do that too :)
Trying to get the same behavior with renovate :)