Re: How hard would it be to implement sparse fetching/pulling?
- Date: Tue, 5 Dec 2017 12:07:26 -0800
- From: Jonathan Nieder <jrnieder@xxxxxxxxx>
- Subject: Re: How hard would it be to implement sparse fetching/pulling?
Jeff Hostetler wrote:
> On 12/2/2017 1:24 PM, Philip Oakley wrote:
>> From: "Jeff Hostetler" <git@xxxxxxxxxxxxxxxxx>
>> Sent: Friday, December 01, 2017 5:23 PM
>>> Discussing this feature in the context of the defense industry
>>> makes me a little nervous. (I used to be in that area.)
>> I'm viewing the desire for codebase partitioning from a soft layering
>> of risk view (perhaps a more UK than USA approach ;-)
> I'm not sure I know what this means or how the UK defense
> security models/policy/procedures are different from the US,
> so I can't say much here. I'm just thinking that even if we
> get a *perfectly working* partial clone/fetch/push/etc. that
> it would not pass a security audit. I might be wrong here
> (and I'm no expert on the subject), but I think they would
> push you towards a different solution architecture.
I'm pretty ignorant about the defense industry, but a few more
- gitolite implements some features on top of git's server code that I
consider to be important for security. So much so that I've been
considering what it would take to remove the git-shell command from
git.git and move it to the gitolite project where people would be
better equipped to use it in an appropriate context
- in particular, git's reachability checking code could use some
hardening/improvement. In particular, think of edge cases like
where someone pushes a pack with deltas referring to objects they
should not be able to reach.
- Anyone willing to audit git code's security wins my approval.
Please, please, audit git code and report the issues you find. :)
> Also omitting certain trees means you now (obviously) have both missing
> trees and blobs. And both need to be dynamically or batch fetched as
> needed. And certain operations will need multiple round trips to fully
> resolve -- fault in a tree and then fault in blobs referenced by it.
For omitting trees, we will need to modify the index format, since the
index has entries for all paths today. That's on the roadmap but has
not been implemented yet.