On 27 November 2012 07:56, Stephen Bash <bash@xxxxxxxxxxx> wrote: > ----- Original Message ----- >> From: "Jason J CTR Pyeron (US)" <jason.j.pyeron.ctr@xxxxxxxx> >> 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. > >> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html