Re: git bundle format [OT]

----- Original Message -----

From: "Jason J CTR Pyeron (US)" <redacted>
Sent: Monday, November 26, 2012 4:06:59 PM
Subject: RE: git bundle format [OT]

quoted

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.

quoted

  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.

quoted

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