"Users of local Git repos and of cloud-based Git services, like BitBucket, GitLab, or GitHub, can rely on password- or SSH-based authentication to keep private repos from view. But that's not as secure as encrypting every file."
Surely it's the same? Ultimately if the private key side of the pair was obtained, you'd be in the same situation.
I think it means that the current encryption only protects it during transit to/from the server. anybody gaining access can just copy your git repository and use/alter it. By encrypting every file they protect from that happening as well.
Once someone can generate a collision to a hashing algorith it's time to start retiring it.
If anyone less than a government can do it now you can bet it's already been done by at least one government for purposes of exploit insertion, because the people most likely to be signing stuff already are those they are likely to be interested in.
Call it the "Price of privacy."
Re: Once someone can generate a collision to a hashing algorith it's time to start retiring it.
But what can you do with your collision in this instance.?
If you have access to the server where the git repository is stored, you can replace one of the files with your own file (not just any old file, your specially crafted file with the same hash) and it won't grumble and people pulling the relevant version will get your file, thinking that it's the original committed by whoever it was who did the previous commit.
Is that a worry? Not really. Even if you can generate collisions easily, you still need write access to the repository. Very rare for you to have that access to a git project worth hacking. Sure it would be better if the vulnerability didn't exist which is why it will eventually get updated to a new algorithm but I can see why it's not high priority.