How is expanding %(describe) during a git archive a denial-of-service (DOS) risk?

Question

The gitattributes man page says:

Creating an archive

export-subst
If the attribute export-subst is set for a file then Git will expand several placeholders when adding this file to an archive. [...] The placeholders are the same as those for the option --pretty=format: of git-log(1), except that they need to be wrapped like this: $Format:PLACEHOLDERS$ in the file. E.g. the string $Format:%H$ will be replaced by the commit hash. However, only one %(describe) placeholder is expanded per archive to avoid denial-of-service attacks.

The git log man page says:

PRETTY FORMATS

[...]

• format:<format-string>

  [...]

  The placeholders are:

  [...]

  • Placeholders that expand to information extracted from the commit:

    [...]

    %(describe[:options])
    human-readable name, like git-describe(1); empty string for undescribable commits. The describe string may be followed by a colon and zero or more comma-separated options. Descriptions can be inconsistent when tags are added or removed at the same time.

In the event that I forgot to tag a recent commit and git describe has to resort to scanning trillions of past commits to find the most recent tag... I can just ^C to terminate git archive. So whose service is being denied in this so called "denial-of-service".

Answer 1

At least GitHub uses git archive to produce archives, and this is also probably the case for GitLab, cgit, and other, similar environments. While GitHub caches archives for a period of time, having very expensive operations and spawning lots of processes is undesirable because it overloads the file servers which store data.

GitHub does have rate-limiting for expensive operations in place, but if archives are extremely expensive, then that means the same repository will see longer delay times for archives, clones, and fetches, and therefore the repository will scale less well. This would also be true if one used cgit on one's own self-hosted code with some sort of CPU or memory cap (e.g., due to a container limit), which also means that similar problems would likely affect sites like kernel.org.

It may be that two or three expansions isn't a problem, but a large number would be, and for now the limit is one, as mentioned in torek's comment.

Answer 2

It is not a denial-of-service risk. Proof:

Problem	Solution
thousands of %(describe)'s slow down an unprotected process	limit everyone to only use one %(describe) per repository
large file uploads crash poorly designed webservers	web browsers limit all file uploads to 1kB/day/host

Both large numbers of %(describe)s and large file uploads can be prevented at the server end (when needed), and thus do not, in themselves, represent a denial of service attack.

I do not understand how this draconian "solution" was signed off on by two, supposedly independent, people. The mindset of severely restricting all users because of bad actions by a small number of users and/or for business benefits sets a dangerous precedent. There are valid, targeted, technical solutions to this problem, as I have demonstrated above.

The real lesson to learn is that git should not be bloated with code for this purpose in the first place, as anyone who needs it can implement their own git-free solution with make and sed. Now that %(describe) is effectively useless in all but the most limited of circumstances, it really is just code bloat. I would recommend not using it.