Re: Proposed approaches to supporting HTTP remotes in "git archive"

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jul 28, 2018, 18:52 UTC
Message-ID: <20180728185251.GB945730@genre.crustytoothpaste.net>
In-Reply-To: <CANq=j3tK7QeBJOC7VNWkh4+WBNibMJJp5YUkd9te5NaYwukAow@mail.gmail.com>

On Fri, Jul 27, 2018 at 02:47:00PM -0700, Josh Steadmon wrote:

Show 28 quoted lines

> ## Use git-upload-archive
> 
> This approach requires adding support for the git-upload-archive
> endpoint to the HTTP backend. Clients will connect to the remote
> server's git-upload-archive service and the server will generate the
> archive which is then delivered to the client.
> 
> ### Benefits
> 
> * Matches existing "git archive" behavior for other remotes.
> 
> * Requires less bandwidth to send a compressed archive than a shallow
>   clone.
> 
> * Resulting archive does not depend in any way on the client
>   implementation.
> 
> ### Drawbacks
> 
> * Implementation is more complicated; it will require changes to (at
>   least) builtin/archive.c, http-backend.c, and
>   builtin/upload-archive.c.
> 
> * Generates more CPU load on the server when compressing archives. This
>   is potentially a DoS vector.
> 
> * Does not allow archiving from servers that don't support the
>   git-upload-archive service.

I happen to like this option because it has the potential to be driven by a non-git client (e.g. a curl invocation). That would be enormously valuable, especially in cases where authentication isn't desired or an SSH key isn't a good form of authentication.

I'm not really worried about the DoS vector because an implementation is almost certainly going to support both SSH and HTTPS or neither, and the DoS potential is the same either way.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204