Re: git bundle format

On 27 November 2012 07:56, Stephen Bash [off-list ref] wrote:

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

quoted

From: "Jason J CTR Pyeron (US)" <redacted>
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.

quoted

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?).

I would propose a slightly different workflow as well, which might
make this process lightly easier. Maybe you are already doing
something like this, but I'll lay it out just in case.

The first step would be to create a 'to-be-publicly-released' branch
within the secret repository, starting from the head of the original
public repository. Rebase all non-secret work to this branch, and
organise it in whatever fashion necessary. This could be, for example,
one single commit representing the sum of all non-secret changes, or
it could be an approximation of the actual history of these changes.

Once this branch has been prepared, you can verify that it branched
from the public repository and that it contains no secret information
using standard git tools or even a patch view of the entire branch.
You can even add a signed tag to the branch once verified to record
who is verifying these changes, and ensuring nothing else gets added
by someone else.

Then you can use 'git bundle fromVerifiedTag.bundle
verifiedTag..public/master' to create a bundle containing just those
commits on the release branch and their associated objects. You can
verify what was included using 'git bundle list-heads
fromVerifiedTag.bundle' to verify what was included.

Perhaps there is a further need to look into the packed objects to
verify nothing else is included, but this workflow should provide more
confidence in the bundled objects in the first place. As for actually
verifying the bundled data after the bundle, I don't know so you would
have to look to the other answers.

Regards,

Andrew Ardill