RE: git bundle format [OT]
Show 14 quoted lines
> -----Original Message-----
> From: Stephen Bash
> Sent: Monday, November 26, 2012 3:56 PM
>
> ----- Original Message -----
> > From: "Jason J CTR Pyeron (US)"
> > Sent: Monday, November 26, 2012 2:24:54 PM
> > Subject: git bundle format
> >
> > I am facing a situation where I would like to use git bundle but at
> > the same time inspect the contents to prevent a spillage[1].
>
> As someone who faced a similar situation in a previous life, I'll offer
> my $0.02, but I'm certainly not the technical expert here.
Kind of what I am looking for as a side effect.
Show 27 quoted lines
>
> > Given we have a public repository which was cloned on to a secret
> > development repository. Now the developers do some work which should
> > not be sensitive in any way and commit and push it to the secret
> > repository.
> >
> > Now they want to release it out to the public. The current process is
> > to review the text files to ensure that there is no "secret" sauce
> > in there and then approve its release. This current process ignores
> > the change tracking and all non-content is lost.
> >
> > In this situation we should assume that the bundle does not have any
> > content which is already in the public repository, that is it has
> > the minimum data to make it pass a git bundle verify from the public
> > repositories point of view. We would then take the bundle and pipe
> > it though the "git-bundle2text" program which would result in a
> > "human" inspectable format as opposed to the packed format[2]. The
> > security reviewer would then see all the information being released
> > and with the help of the public repository see how the data changes
> > the repository.
> >
> > Am I barking up the right tree?
>
> First, a shot out of left field: how about a patch based workflow?
> (similar to the mailing list, just replace email with sneakernet)
> Patches are plain text and simple to review (preferable to an "opaque"
> binary format?).
This is to only address the accidental development on a high side. Using this or any process should come with shame or punishment for wasting resources/time by not developing on a low side to start with. But accepting reality there will be times where code and its metadata (commit logs, etc) will be created on a high side and should be brought back to the low side.
> Second, thinking about your proposed bundle-based workflow I have two
> questions I'd have to answer to be comfortable with the solution:
>
> 1) Does the binary bundle contain any sensitive information?
Potentially, hence the review. If the reviewer cannot prove the data he is looking at then the presumption is yes.
> 2) Do the diffs applied to public repo contain any sensitive data?
That is a great question. Can the change of code while neither the original or the resultant be secret while the change imply or demonstrate the secret. I think the answer is yes.
Show 9 quoted lines
>
> Question 1 seems tricky to someone who knows *nothing* about the bundle
> format (e.g. me). Maybe some form of bundle2text can be vetted enough
> that everyone involved believes that there is no other information
> traveling with the bundle (if so, you're golden). Here I have to trust
> other experts. On the flip side, even if the bundle itself is polluted
> (or considered to be lacking proof to the contrary), if (2) is
> considered safe, the patching of the public repo could potentially be
> done on a sacrificial hard drive before pushing.
The logistics are well established and here and now is not a place to go in to that. But the above is the crux of what I am trying to get at.
Show 12 quoted lines
>
> Question 2 is relatively straight forward and lead me to the patch
> idea. I would:
> - Bundle the public repository
> - Init a new repo in the secure space from the public bundle
> - Fetch from the to-be-sanitized bundle into the new repo
> - Examine commits (diffs) introduced by branches in the to-be-
> sanitized bundle
> - Perhaps get a list of all the objects in the to-be-sanitized bundle
> and do a git-cat-file on each of them (if the bundle is assembled
> correctly it shouldn't have any unreachable objects...). This step may
> be extraneous after the previous.
Here we would be missing the metadata that goes along with the commit. Especially the SHA sums.
Thanks.
-Jason