Nick Thomas authored Oct 15, 2019 and Patrick Bajao committed Nov 21, 2019

In most cases, Gitaly trusts that the caller of the RPC has validated
that the user is permitted to perform the action represented by the RPC
and doesn't repeat any access control checks. Where an RPC reads data
from a client-controlled stream before acting, the time between the
check and the operation can be artificially extended. This can lead to
security issues where

Solve this by placing a limit on the *negotiation phase* of two RPCs
that are known to be vulnerable:

* ssh.SSHUploadPack
* ssh.SSHUploadArchive

These RPCs are known not to be vulnerable, for one reason or another:

* ssh.SSHReceivePack
* smarthttp.ReceivePack

The smarthttp.UploadPack RPC is vulnerable, but the vulnerability is
being handled in Workhorse.