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.
