Re: [RFE] Inverted sparseness (amended)

["Philip Oakley" <philipoakley@iee.org>]

From: "Randall S. Becker" <rsbecker@nexbridge.com>
On December 3, 2017 6:14 PM, Philip Oakley wrote a nugget of wisdom:
>From: "Randall S. Becker" <rsbecker@nexbridge.com>
[...]

>If using the empty tree part doesn't pass muster (i.e. showing nothing
>isn't sufficient), then the narrow clone could come into play to limit
>what parts of the trees are widely visible, but mainly its using the
>grafts to cover the regulatory gap, and (for the moment) using
>fast-export to transfer the singleton commit / tags

>Oh Just remembered, there is the newish capability to fetch random blobs, 
>so that may help.

I think you hit the nail on the head pretty well. We're currently at 2.3.7, 
with a push to 2.15.1 this week, so I'm looking forward to trying this. My 
two worries are whether the empty tree is acceptable (it should be to the 
client, and might be to the vendor), and doing this reliably 
(semi-automated) so the user base does not have to worry about the gory 
details of doing this. The unit tests for it are undoubtedly going to give 
me headaches.

Thanks for the advice. Islands of shallowness are a really descriptive image 
for what this is. So identifying that there are shoals (to extend the 
metaphor somewhat), will be crucial to this adventure.

These islands of shallowness, however, are also concerns as described in the 
[Re: How hard would it be to implement sparse fetching/pulling?] thread. The 
matter of the security audit is important here also:
> 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.


Philip says:
I'd totally disagree in the sense that if we had a submodule anywhere_ in 
the repo that would be an independent island of code, and we are quite happy 
with that - we use the web of trust with the auditors for them to go check, 
separately, the oid of the independent portion, which may be at another site 
or another vendor/client. That's OK, so what's the problem here...

We do the same for pinning the tips and tails of the lines of development 
that make for the shallowness and narrowness that create these shoals, and 
oxbows of development. Managing them is normal human activity, with the 
technical support that the Git chain provides - so much better than previous 
'versioning systems' that we see regularly in engineering, with backdoor 
tweaks etc.

The key is to ensure that there is a proper hand holding across the air 
gaps, such that the oids exist both sides of the gaps, and a properly built 
on, such that the hash chain is unbroken. It's a similar negotiation to 
those used for establishing web security between IP clients, so it is 
doable. But you are right to have concerns and suspisions to ensure that it 
is all tested and verified
--
Philip (sorry about the poor quoting of the reply)




Not having the capability would similarly cause a failure of a security 
audit.

Cheers,
Randall

-- Brief whoami: NonStop&UNIX developer since approximately 
UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.