>If you know the hash of some data, then you either already have the data yourself, or you learned the hash from someone who had the data.

From the article, you do not need to have the data nor learn the hash from someone who had the data.

>Commit hashes can be brute forced through GitHub’s UI, particularly because the git protocol permits the use of short SHA-1 values when referencing a commit. A short SHA-1 value is the minimum number of characters required to avoid a collision with another commit hash, with an absolute minimum of 4. The keyspace of all 4 character SHA-1 values is 65,536

In which case, yeah, thats a vulnerability. They shouldn't allow a short hash to match up against anything but public data.

It's common to use short hash in pull request, and then modify or rebase the commits.

The solutions are:

* Force people to use the full hash.

* Get use to a lot of dead links.

* Claim that it's a feature, not a bug.

* Force people to use the full hash for commits pushed now on?

* Check visibility at the time of posting.

> If you know the hash of some data, then you either already have the data yourself, or you learned the hash from someone who had the data.

Don’t think so - the article mentions you can use the short prefix on GitHub, so you have a search space of 65536.

> If you know the hash of some data, then you either already have the data yourself, or you learned the hash from someone who had the data.

You need to read to the end of the article where they show the brute-force way of getting the hashes.

That's counterintuitive, though - often, the whole point of a hash is that it's one-way.

Read TFA.