Use GitHub actions at your own risk
julienrenaux.fr
julienrenaux.fr
Anything you use in a critical path you should control. If you're managing your own fork, nobody will inject bad code except yourself.
Just my 2 cents. Also, the things that github 3rd party actions are doing is usually not that complicated. I mean how many different ways can you publish a docker image or deploy an artifact to S3. Once it works, it either works or doesn't. It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).
Sorry minor rant. food for thought.
Do I do this for hobby projects? No, of course not. If my toy projects break, meh. But for production? Where breakage actually costs money? Damn right I do.
It's not only breakage, though. You want a hermetic build system, so you can build software reproducibly and consistently. There are few things more "fun" than building "the same" code on two machines, and one executable has a bug while the second doesn't. (OK. Compiler bugs are even more fun)
Many automated vendor/package management tools will not automate pulling newer changes from upstream. If this was instead a simple a read-only version/tag, it is easy for those tools to provide upgrade/update path.
There is no bright line delimitating what's on the "critical path" and what's not. Your servers? The electric grid? The datacenter? The backbone(s) it's connected to? The judicial system making contracts enforceable? NATO? Name any two that straddle the line, and anybody can come up with something in between them, because it's a continuum.
It's not unreasonable to be more concerned about an open source library disappearing than say, postgresql or mysql disappearing. No macho posturing required.
Let's say I'm working front-end web development. My "critical path" might include: js bundler, some kind of application framework, various libs, etc. The scope of my work (and authority/responsibility) informs what I can reasonably have under my control.
What's the chance of the grid going down? What's the cost of it? Is the expected value significantly higher than a power generator? Congrats, you just bought a power generator.
Backbone down would cause you huge financial losses? Well, whaddaya say, let's build more backbone.[1]
Any redundancy that costs significantly less than the losses it mitigates will be built. The only reason we're not seeing a private NATO yet is that it costs more than pretty much any company makes. But 5,000 people security forces? Damn skippy those exist[2]
[1] https://engineering.fb.com/data-center-engineering/building-... [2] https://www.businessinsider.com/facebook-off-duty-police-off...
https://en.wikipedia.org/wiki/Not_invented_here
?
> It's not a programming library where optimizations are created or we fixed a security vulnerability (though I suppose that can come up ).
But it's a service provided by a paid-for entity which has support which you pay for. If it doesn't work, you let support know....
Likely, you can still do this and migrate people fairly painlessly to a secure version.
Edit: even if you select a tag or something, it should use the underlying reference instead of the tag. You can add an escape hatch if you REALLY want to target the tag (there are obviously workflows where that makes sense), but it should be off by default and warm users of the security risks.
Still, recommending git SHAs has real ergonomic and maintainability issues, and while it’s more defensive it doesn’t prevent left-pad style broken builds due to disappearing content.
And at the same time, GitHub is investing heavily in package management infrastructure. I don’t say this lightly because designing good dependency management systems is much more subtle and difficult than people typically recognize, but from where I sit this appears to be fundamentally a dependency management concern. It seems a shame not to try to put GitHub Package Registry to good work here. Is that something potentially on the horizon?
If I'm using a marketplace action in my workflow, I want "foo/action@v1.0.0" to be treated like a binary package dependency, not a build from sourcecode.
With Gitlab.com:
https://docs.gitlab.com/ee/user/packages/container_registry/
We're really not even pulling the dependency locally, we're just going to run someone else's code from their repo, on github's server, with our data and secrets?
What could possibly go wrong with that? /s
It's a relevant distinction on this context.
There's something to be said for on-premise solutions, but they won't save you from a malicious maintainer.
I am thinking specifically about: * Gitlab's CI * CircleCI * TeamCity
etc....
That's super valuable because you get started faster - e.g. "oh here's how I can deploy a lambda" but brings up this security concern of running other people's code. As discussed in the article, this is something NPM solved after the left-pad debacle. And I am sure (I hope) that GitHub will either change the documentation or add features to prevent this.
However, you'll sometimes want to update the commit hash after the action's maintainer releases new code. If you don't then you run the risk of running an old action that has vulnerable components or bugs.
The easiest workflow for that should be Dependabot's updater for GitHub actions: https://dependabot.com/github-actions/ Has anyone tried that approach for GitHub actions?
You still need to review the action's code before you use it, and every time you update to a new commit hash. But this approach protects you from automatically running new malicious code pushed to master/re-tagged.
I thought SHA-1 wasn't considered secure?
Here is Linus on SHA-1 in git: https://www.theregister.co.uk/2017/02/26/git_fscked_by_sha1_...
That said, hashes like md5 are still plenty used in ETags for http 304s all the time despite being considered insecure for cryptographic use.
However, to rewrite history you need a preimage attack. In other words, you need to find a value X which hashes to the same hash value y which already exists h(X)=y
These are not currently practical. So SHA1 is certainly not recommended, but isn't completely broken yet.
Git uses hashes that include more data than just the hash of the content of an object. Meaning the existing known collisions don't work and you'd have to develop collisions specifically to target git.
Additionally, the current known collision attacks require generating the two colliding contents as a pair. You can't take an existing document and then generate a collision for that document. Further, the technique is not particularly good for text documents because you need to include some data to force the collision. This is easily missed in binary documents but not the text documents most people are committing into git repos (granted you can put binary files into git and that would still work but the other reasons for this not being very useful still apply).
Git also has code to deal with possible collisions and will fall back to full comparison and will fail a commit that creates a collision. Finally, generating these document pairs leaves detectable patterns in the content. GitHub scans for these patterns as part of their process.
https://github.blog/2017-03-20-sha-1-collision-detection-on-...
Just a recap: generating two files who's hashes collide takes 2^80 tries if SHA-1 wasn't broken, whereas finding a file with the same hash as a specific, externally-determined file takes 2^160 tries.
I mean, there is an action in the marketplace that runs git-crypt to decrypt your files. With this issue, no user should ever be using this action without forking it to their repo first.
Currently the closest equivalents are making a request via the API (but then you need a token with it, and all the security concerns it opens) or sending a special message using an empty commit (but I haven't found a simple way to do that from inside VSCode, unless I missed it somewhere).