11–20 of 65 posts
> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. I thought SHA-1 wasn't considered secure?
> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. 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_...
> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. I thought SHA-1 wasn't considered secure?
That said, hashes like md5 are still plenty used in ETags for http 304s all the time despite being considered insecure for cryptographic use.
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
> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. I thought SHA-1 wasn't considered secure?
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.
> Each hash is supposed to be unique and you cannot rewrite history with the exact same SHA-1. I thought SHA-1 wasn't considered secure?
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-...
Sorry, that whole github actions concept gives me the screaming heeby-jeebies. 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
I am thinking specifically about: * Gitlab's CI * CircleCI * TeamCity
etc....
This also applies to most library, docker (as mentioned) and basically anything you use that's 3rd party. I suppose it varies on your level of paranoia, though honestly if you rely on a github action in your production flow you should fork the project. Never mind doing something malicious, they could just as easily delete the entire repo and now your critical feature you needed to deliver are blocked because the libr…