git archive invocation using sha1 to specify commit

git archive invocation using sha1 to specify commit

[Zdenek Crha]

CC me on answers please, since I'm not subscribed to the list

Hello,

I would like to ask a question about commit restriction added to git
archive by commit (ee27ca4a: archive: don't let remote clients get
unreachable commits, 2011-11-17) and following efforts to loosen them
a bit.

In out company we are using git together with source indexing. We
store a git command for retrieval of source code file that was used
for building into pdb file(s). Currently, we are using an invocation
of git archive with --remote parameter and commit sha1 to export
exactly the source code that was used for build.

The above mentioned commit removed possibility to do that. I have read
about efforts to loosen the restrictions,
but I'm not sure whenever ability to export arbitrary sha1 will be
allowed too. Can anybody clarify that for me please?

Regards,
Zdenek Crha

Re: git archive invocation using sha1 to specify commit

[Junio C Hamano]

Zdenek Crha <zdenek.crha@gmail.com> writes:

> In out company we are using git together with source indexing. We
> store a git command for retrieval of source code file that was used
> for building into pdb file(s). Currently,...
> ... I'm not sure whenever ability to export arbitrary sha1 will be
> allowed too.

No, that will be a premium feature that your company _could_ pay for with
the source of that "source indexing" system ;-)

Jokes aside, this was part of a security tightening to make sure nobody
could reach something that cannot be obtained by cloning, without incurring
large computation overhead.

Theoretically we could selectively loosen the restriction [*1*], but it is
not very high on our priority list.


[Footnote]

*1* When the given starting point is a raw SHA-1, we could run a single
merge_bases_many() to see if any of the refs can reach it, and only serve
the tree the check passes, or something.

Re: git archive invocation using sha1 to specify commit

[Jeff King]

On Wed, Feb 29, 2012 at 08:45:55AM +0100, Zdenek Crha wrote:

> I would like to ask a question about commit restriction added to git
> archive by commit (ee27ca4a: archive: don't let remote clients get
> unreachable commits, 2011-11-17) and following efforts to loosen them
> a bit.
> 
> In out company we are using git together with source indexing. We
> store a git command for retrieval of source code file that was used
> for building into pdb file(s). Currently, we are using an invocation
> of git archive with --remote parameter and commit sha1 to export
> exactly the source code that was used for build.
> 
> The above mentioned commit removed possibility to do that. I have read
> about efforts to loosen the restrictions,
> but I'm not sure whenever ability to export arbitrary sha1 will be
> allowed too. Can anybody clarify that for me please?

The plans for loosening are still up in the air, as we didn't have real
data on whether people were using this feature or not. I do have patches
ready that loosen the restriction based on the details of the name
lookup, which would allow things which started a traversal from a ref,
like "foo~5". But it would explicitly not allow an arbitrary sha1.

The only way to correctly handle an arbitrary sha1 is to actually do a
reachability analysis from the refs. That's what we do with upload-pack
(which handles regular fetch and clone requests). However, handling the
general case of fetching an arbitrary tree would mean we would have to
look inside every commit to see if it contains the tree. And that can
get a bit expensive. It sounds like you are just asking for a commit
sha1, so for your case we could get away with just handling sha1s of
commits, and only allowing trees that are referenced by commit (e.g.,
"HEAD~5:subdir") or have an exact ref pointing to them (e.g., like the
linux v2.6.11-tree tag).

Yet another option would be to add a config option on the server repo to
turn off this safety check for git-archive. That is simple to do, and
sounds like it would handle your use case, as you control the repo. One
downside is that it is the server admin who must turn on the config
option, whereas it is the clients of the repo who might want to make the
bare-sha1 request. In a company, the admins (usually) have to listen to
the clients, but that is not always the case.

-Peff