Web lists-archives.com

Re: [RFE] Inverted sparseness (amended)




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

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.