Re: git bundle format [OT]
----- Original Message -----
Show 13 quoted lines
> From: "Jason J CTR Pyeron (US)" <jason.j.pyeron.ctr@mail.mil>
> Sent: Monday, November 26, 2012 4:06:59 PM
> Subject: RE: git bundle format [OT]
>
> > 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.
Ah, if only more of those I (previously) worked with thought as you do :)
> 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.
Using git format-patch and git am it's possible to retain the commit messages (and other associated metadata). But again, I'm not the expert on this :) I've made it work a few times to test patches from this list, but so far I've avoided serious integration into the mailing list workflow.
Show 6 quoted lines
> > 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.
In actual fact I was thinking about the simple case where the result included an "Eek! 3.1415926 cannot show up in this code!" (sometimes that's easier to see in a diff than a full text blob). Obviously the first line of defense should catch such mistakes. But yes, your point is also a good one. I'd be hard pressed to argue that a particular series of commits leaks information on their own, but they can certainly corroborate other available information.
Show 14 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.
Ah sorry, I guess I wasn't complete. Once that process has been done on the high side one has to go back to question 1 and see if it's safe to move the bundle out to repeat the process on the low side.
Stephen