{"thread":{"id":"32202","subject":"git bundle format","startedAt":"2012-11-26T19:24:54Z","lastAt":"2012-11-26T23:08:21Z","messageCount":11,"participants":["Pyeron, Jason J CTR (US)","Felipe Contreras","Junio C Hamano","Stephen Bash","Andrew Ardill"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"203908","messageId":"871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil","threadId":"32202","inReplyTo":null,"subject":"git bundle format","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-26T19:24:54Z","receivedAt":"2012-11-26T19:24:54Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"I may need to be nudged in a better direction, but please try to understand my intentions.\n\nI 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].\n\nGiven 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.\n\nNow 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.\n\n\nIn 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.\n\nAm I barking up the right tree?\n\n\n1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information\n2: http://git-scm.com/book/ch9-4.html\n\n"},{"id":"203909","messageId":"871B6C10EBEFE342A772D1159D13208537ABF5CB@umechphj.easf.csd.disa.mil","threadId":"32202","inReplyTo":"871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil","subject":"RE: git bundle format","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-26T19:31:02Z","receivedAt":"2012-11-26T19:31:02Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"Left off a citation to an old thread.\n\n> -----Original Message-----\n> From: Pyeron, Jason J CTR (US)\n> Sent: Monday, November 26, 2012 2:25 PM\n> \n> I may need to be nudged in a better direction, but please try to\n> understand my intentions.\n> \n> I am facing a situation where I would like to use git bundle but at the\n> same time inspect the contents to prevent a spillage[1].\n> \n> Given we have a public repository which was cloned on to a secret\n> development repository. Now the developers do some work which should\n> not be sensitive in any way and commit and push it to the secret\n> repository.\n> \n> Now they want to release it out to the public. The current process is\n> to review the text files to ensure that there is no \"secret\" sauce in\n> there and then approve its release. This current process ignores the\n> change tracking and all non-content is lost.\n> \n> \n> In this situation we should assume that the bundle does not have any\n> content which is already in the public repository, that is it has the\n> minimum data to make it pass a git bundle verify from the public\n> repositories point of view. We would then take the bundle and pipe it\n> though the \"git-bundle2text\" program which would result in a \"human\"\n> inspectable format\n[3]\n> as opposed to the packed format[2]. The security\n> reviewer would then see all the information being released and with the\n> help of the public repository see how the data changes the repository.\n> \n> Am I barking up the right tree?\n> \n> \n> 1: http://en.wikipedia.org/wiki/Spillage_of_Classified_Information\n> 2: http://git-scm.com/book/ch9-4.html\n3: http://git.661346.n2.nabble.com/How-to-extract-files-out-of-a-quot-git-bundle-quot-no-matter-what-td1679188.html\n"},{"id":"203914","messageId":"CAMP44s03QiO15jODBD4JO_JF8tCOT9OJG1tb4+r+L4dgPUOLFg@mail.gmail.com","threadId":"32202","inReplyTo":"871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil","subject":"Re: git bundle format","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-26T20:20:15Z","receivedAt":"2012-11-26T20:20:15Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)\n wrote:\n> I may need to be nudged in a better direction, but please try to understand my intentions.\n>\n> 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].\n>\n> 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.\n>\n> 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.\n>\n>\n> 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.\n>\n> Am I barking up the right tree?\n\nHave you tried 'git fast-export'? The output is definitely not human\ninspectable, but should be relatively easy to parse to generate such a\nformat. And instead of 'git bundle unbundle' you could use 'git\nfast-import'. or simply do the conversion in your script.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203918","messageId":"7vvccsqeva.fsf@alter.siamese.dyndns.org","threadId":"32202","inReplyTo":"871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil","subject":"Re: git bundle format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-11-26T20:38:17Z","receivedAt":"2012-11-26T20:38:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Pyeron, Jason J CTR (US)\" writes:\n\n> In this situation we should assume that the bundle does not have\n> any content which is already in the public repository, that is it\n> has the minimum data to make it pass a git bundle verify from the\n> public repositories point of view. We would then take the bundle\n> and pipe it though the \"git-bundle2text\" program which would\n> result in a \"human\" inspectable format as opposed to the packed\n> format[2]. The security reviewer would then see all the\n> information being released and with the help of the public\n> repository see how the data changes the repository.\n\nThe bundle file is a thinly wrapped packfile, with extra information\nthat tells what objects in the bundle are the tips of histories and\nwhat objects the repository the bundle gets unbundled has to have.\nSo your \"git-bundle2text\" would likely to involve fetching from the\nbundle and inspecting the resulting history and the working tree\nfiles.\n"},{"id":"203921","messageId":"871B6C10EBEFE342A772D1159D13208537ABF676@umechphj.easf.csd.disa.mil","threadId":"32202","inReplyTo":"CAMP44s03QiO15jODBD4JO_JF8tCOT9OJG1tb4+r+L4dgPUOLFg@mail.gmail.com","subject":"RE: git bundle format","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-26T20:50:11Z","receivedAt":"2012-11-26T20:50:11Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Felipe Contreras\n> Sent: Monday, November 26, 2012 3:20 PM\n> \n> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)\n> wrote:\n> > I may need to be nudged in a better direction, but please try to\n> understand my intentions.\n> >\n> > I am facing a situation where I would like to use git bundle but at\n> the same time inspect the contents to prevent a spillage[1].\n> >\n\n> >\n> > Am I barking up the right tree?\n> \n> Have you tried 'git fast-export'? The output is definitely not human\n> inspectable, but should be relatively easy to parse to generate such a\n> format. And instead of 'git bundle unbundle' you could use 'git\n> fast-import'. or simply do the conversion in your script.\n\nNo. But I am going to read up on it today. It clearly says \"You can use it as a human-readable bundle replacement\"[4]. My initial question is does it ever use deltas? The repositories I just tested it on only seem to output full blobs (which is really nice from this use case point of view).\n\n-Jason\n\n\n4: http://www.kernel.org/pub/software/scm/git/docs/git-fast-export.html\n"},{"id":"203922","messageId":"871B6C10EBEFE342A772D1159D13208537ABF68B@umechphj.easf.csd.disa.mil","threadId":"32202","inReplyTo":"7vvccsqeva.fsf@alter.siamese.dyndns.org","subject":"RE: git bundle format","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-26T20:53:43Z","receivedAt":"2012-11-26T20:53:43Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Junio C Hamano\n> Sent: Monday, November 26, 2012 3:38 PM\n> \n> \"Pyeron, Jason J CTR (US)\" writes:\n> \n> > In this situation we should assume that the bundle does not have\n> > any content which is already in the public repository, that is it\n> > has the minimum data to make it pass a git bundle verify from the\n> > public repositories point of view. We would then take the bundle\n> > and pipe it though the \"git-bundle2text\" program which would\n> > result in a \"human\" inspectable format as opposed to the packed\n> > format[2]. The security reviewer would then see all the\n> > information being released and with the \n\n*** Assumed that the inspector had a copy of the original public repo\n\n> > help of the public\n> > repository see how the data changes the repository.\n\n\n\n> \n> The bundle file is a thinly wrapped packfile, with extra information\n> that tells what objects in the bundle are the tips of histories and\n> what objects the repository the bundle gets unbundled has to have.\n> So your \"git-bundle2text\" would likely to involve fetching from the\n> bundle and inspecting the resulting history and the working tree\n> files.\n\nYea, I knew the inspection tool was going to get messy.\n\n-Jason\n"},{"id":"203924","messageId":"CAMP44s0x17AkYenj8HyXNpkgrPOXtB72dpFOvik882ESohPb7w@mail.gmail.com","threadId":"32202","inReplyTo":"871B6C10EBEFE342A772D1159D13208537ABF676@umechphj.easf.csd.disa.mil","subject":"Re: git bundle format","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2012-11-26T20:56:14Z","receivedAt":"2012-11-26T20:56:14Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Mon, Nov 26, 2012 at 9:50 PM, Pyeron, Jason J CTR (US)\n wrote:\n>> -----Original Message-----\n>> From: Felipe Contreras\n>> Sent: Monday, November 26, 2012 3:20 PM\n>>\n>> On Mon, Nov 26, 2012 at 8:24 PM, Pyeron, Jason J CTR (US)\n>> wrote:\n>> > I may need to be nudged in a better direction, but please try to\n>> understand my intentions.\n>> >\n>> > I am facing a situation where I would like to use git bundle but at\n>> the same time inspect the contents to prevent a spillage[1].\n>> >\n> \n>> >\n>> > Am I barking up the right tree?\n>>\n>> Have you tried 'git fast-export'? The output is definitely not human\n>> inspectable, but should be relatively easy to parse to generate such a\n>> format. And instead of 'git bundle unbundle' you could use 'git\n>> fast-import'. or simply do the conversion in your script.\n>\n> No. But I am going to read up on it today. It clearly says \"You can use it as a human-readable bundle replacement\"[4].\n\nAh, didn't notice that.\n\n> My initial question is does it ever use deltas?\n\nNo.\n\n> The repositories I just tested it on only seem to output full blobs (which is really nice from this use case point of view).\n\nIn my experience it's nice for most use-cases. Since git only deals\nwith full file contents, that makes sense.\n\nCheers.\n\n-- \nFelipe Contreras\n"},{"id":"203925","messageId":"1745253724.103630.1353963384110.JavaMail.root@genarts.com","threadId":"32202","inReplyTo":"871B6C10EBEFE342A772D1159D13208537ABF5AB@umechphj.easf.csd.disa.mil","subject":"Re: git bundle format","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2012-11-26T20:56:24Z","receivedAt":"2012-11-26T20:56:24Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Jason J CTR Pyeron (US)\" \n> Sent: Monday, November 26, 2012 2:24:54 PM\n> Subject: git bundle format\n> \n> I am facing a situation where I would like to use git bundle but at\n> the same time inspect the contents to prevent a spillage[1].\n\nAs 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.\n\n> Given we have a public repository which was cloned on to a secret\n> development repository. Now the developers do some work which should\n> not be sensitive in any way and commit and push it to the secret\n> repository.\n> \n> Now they want to release it out to the public. The current process is\n> to review the text files to ensure that there is no \"secret\" sauce\n> in there and then approve its release. This current process ignores\n> the change tracking and all non-content is lost.\n> \n> In this situation we should assume that the bundle does not have any\n> content which is already in the public repository, that is it has\n> the minimum data to make it pass a git bundle verify from the public\n> repositories point of view. We would then take the bundle and pipe\n> it though the \"git-bundle2text\" program which would result in a\n> \"human\" inspectable format as opposed to the packed format[2]. The\n> security reviewer would then see all the information being released\n> and with the help of the public repository see how the data changes\n> the repository.\n> \n> Am I barking up the right tree?\n\nFirst, 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?).\n\nSecond, thinking about your proposed bundle-based workflow I have two questions I'd have to answer to be comfortable with the solution:\n\n 1) Does the binary bundle contain any sensitive information?\n 2) Do the diffs applied to public repo contain any sensitive data?\n\nQuestion 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.\n\nQuestion 2 is relatively straight forward and lead me to the patch idea. I would:\n - Bundle the public repository\n - Init a new repo in the secure space from the public bundle\n - Fetch from the to-be-sanitized bundle into the new repo\n - Examine commits (diffs) introduced by branches in the to-be-sanitized bundle\n - 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.\n\nHTH,\nStephen\n"},{"id":"203931","messageId":"871B6C10EBEFE342A772D1159D13208537ABF6D3@umechphj.easf.csd.disa.mil","threadId":"32202","inReplyTo":"1745253724.103630.1353963384110.JavaMail.root@genarts.com","subject":"RE: git bundle format [OT]","fromName":"Pyeron, Jason J CTR (US)","fromEmail":"jason.j.pyeron.ctr@mail.mil","sentAt":"2012-11-26T21:06:59Z","receivedAt":"2012-11-26T21:06:59Z","isPatch":false,"sender":{"key":"jason.j.pyeron.ctr@mail.mil","avatar":null},"body":"> -----Original Message-----\n> From: Stephen Bash\n> Sent: Monday, November 26, 2012 3:56 PM\n> \n> ----- Original Message -----\n> > From: \"Jason J CTR Pyeron (US)\" \n> > Sent: Monday, November 26, 2012 2:24:54 PM\n> > Subject: git bundle format\n> >\n> > I am facing a situation where I would like to use git bundle but at\n> > the same time inspect the contents to prevent a spillage[1].\n> \n> As someone who faced a similar situation in a previous life, I'll offer\n> my $0.02, but I'm certainly not the technical expert here.\n\nKind of what I am looking for as a side effect.\n\n> \n> > Given we have a public repository which was cloned on to a secret\n> > development repository. Now the developers do some work which should\n> > not be sensitive in any way and commit and push it to the secret\n> > repository.\n> >\n> > Now they want to release it out to the public. The current process is\n> > to review the text files to ensure that there is no \"secret\" sauce\n> > in there and then approve its release. This current process ignores\n> > the change tracking and all non-content is lost.\n> >\n> > In this situation we should assume that the bundle does not have any\n> > content which is already in the public repository, that is it has\n> > the minimum data to make it pass a git bundle verify from the public\n> > repositories point of view. We would then take the bundle and pipe\n> > it though the \"git-bundle2text\" program which would result in a\n> > \"human\" inspectable format as opposed to the packed format[2]. The\n> > security reviewer would then see all the information being released\n> > and with the help of the public repository see how the data changes\n> > the repository.\n> >\n> > Am I barking up the right tree?\n> \n> First, a shot out of left field: how about a patch based workflow?\n> (similar to the mailing list, just replace email with sneakernet)\n> Patches are plain text and simple to review (preferable to an \"opaque\"\n> binary format?).\n\nThis 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.\n\n\n> Second, thinking about your proposed bundle-based workflow I have two\n> questions I'd have to answer to be comfortable with the solution:\n> \n> 1) Does the binary bundle contain any sensitive information?\n\nPotentially, hence the review. If the reviewer cannot prove the data he is looking at then the presumption is yes.\n\n> 2) Do the diffs applied to public repo contain any sensitive data?\n\nThat 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.\n\n> \n> Question 1 seems tricky to someone who knows *nothing* about the bundle\n> format (e.g. me). Maybe some form of bundle2text can be vetted enough\n> that everyone involved believes that there is no other information\n> traveling with the bundle (if so, you're golden). Here I have to trust\n> other experts. On the flip side, even if the bundle itself is polluted\n> (or considered to be lacking proof to the contrary), if (2) is\n> considered safe, the patching of the public repo could potentially be\n> done on a sacrificial hard drive before pushing.\n\nThe 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.\n \n> \n> Question 2 is relatively straight forward and lead me to the patch\n> idea. I would:\n> - Bundle the public repository\n> - Init a new repo in the secure space from the public bundle\n> - Fetch from the to-be-sanitized bundle into the new repo\n> - Examine commits (diffs) introduced by branches in the to-be-\n> sanitized bundle\n> - Perhaps get a list of all the objects in the to-be-sanitized bundle\n> and do a git-cat-file on each of them (if the bundle is assembled\n> correctly it shouldn't have any unreachable objects...). This step may\n> be extraneous after the previous.\n\nHere we would be missing the metadata that goes along with the commit. Especially the SHA sums.\n\nThanks.\n\n-Jason\n"},{"id":"203934","messageId":"484658581.104406.1353965469300.JavaMail.root@genarts.com","threadId":"32202","inReplyTo":"871B6C10EBEFE342A772D1159D13208537ABF6D3@umechphj.easf.csd.disa.mil","subject":"Re: git bundle format [OT]","fromName":"Stephen Bash","fromEmail":"bash@genarts.com","sentAt":"2012-11-26T21:31:09Z","receivedAt":"2012-11-26T21:31:09Z","isPatch":false,"sender":{"key":"bash@genarts.com","avatar":null},"body":"----- Original Message -----\n> From: \"Jason J CTR Pyeron (US)\" \n> Sent: Monday, November 26, 2012 4:06:59 PM\n> Subject: RE: git bundle format [OT]\n> \n> > First, a shot out of left field: how about a patch based workflow?\n> > (similar to the mailing list, just replace email with sneakernet)\n> > Patches are plain text and simple to review (preferable to an\n> > \"opaque\" binary format?).\n> \n> This is to only address the accidental development on a high side.\n> Using this or any process should come with shame or punishment for\n> wasting resources/time by not developing on a low side to start\n> with.\n\nAh, if only more of those I (previously) worked with thought as you do :)\n\n> But accepting reality there will be times where code and its\n> metadata (commit logs, etc) will be created on a high side and\n> should be brought back to the low side.\n\nUsing 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.\n\n> > 2) Do the diffs applied to public repo contain any sensitive\n> > data?\n> \n> That is a great question. Can the change of code while neither the\n> original or the resultant be secret while the change imply or\n> demonstrate the secret. I think the answer is yes.\n\nIn 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.\n\n> > Question 2 is relatively straight forward and lead me to the patch\n> > idea. I would:\n> > - Bundle the public repository\n> > - Init a new repo in the secure space from the public bundle\n> > - Fetch from the to-be-sanitized bundle into the new repo\n> > - Examine commits (diffs) introduced by branches in the to-be-\n> > sanitized bundle\n> > - Perhaps get a list of all the objects in the to-be-sanitized\n> > bundle and do a git-cat-file on each of them (if the bundle is\n> > assembled correctly it shouldn't have any unreachable objects...).\n> > This step may be extraneous after the previous.\n> \n> Here we would be missing the metadata that goes along with the\n> commit. Especially the SHA sums.\n\nAh 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. \n \nStephen\n"},{"id":"203947","messageId":"CAH5451mB0_5r6pK43OBxoo8HVAteRgv3fKrE0iCu3c=tcZt_nA@mail.gmail.com","threadId":"32202","inReplyTo":"1745253724.103630.1353963384110.JavaMail.root@genarts.com","subject":"Re: git bundle format","fromName":"Andrew Ardill","fromEmail":"andrew.ardill@gmail.com","sentAt":"2012-11-26T23:08:21Z","receivedAt":"2012-11-26T23:08:21Z","isPatch":false,"sender":{"key":"andrew.ardill@gmail.com","avatar":"https://gravatar.com/avatar/da14cb7c091dd44dc6c63a4d3361b149acaf25226dc78eb4131a17b93d9b0993?d=mp&s=160"},"body":"On 27 November 2012 07:56, Stephen Bash wrote:\n> ----- Original Message -----\n>> From: \"Jason J CTR Pyeron (US)\" \n>> Sent: Monday, November 26, 2012 2:24:54 PM\n>> Subject: git bundle format\n>>\n>> I am facing a situation where I would like to use git bundle but at\n>> the same time inspect the contents to prevent a spillage[1].\n>\n> 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.\n>\n>> Given we have a public repository which was cloned on to a secret\n>> development repository. Now the developers do some work which should\n>> not be sensitive in any way and commit and push it to the secret\n>> repository.\n>>\n>> Now they want to release it out to the public. The current process is\n>> to review the text files to ensure that there is no \"secret\" sauce\n>> in there and then approve its release. This current process ignores\n>> the change tracking and all non-content is lost.\n>>\n>> In this situation we should assume that the bundle does not have any\n>> content which is already in the public repository, that is it has\n>> the minimum data to make it pass a git bundle verify from the public\n>> repositories point of view. We would then take the bundle and pipe\n>> it though the \"git-bundle2text\" program which would result in a\n>> \"human\" inspectable format as opposed to the packed format[2]. The\n>> security reviewer would then see all the information being released\n>> and with the help of the public repository see how the data changes\n>> the repository.\n>>\n>> Am I barking up the right tree?\n>\n> 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?).\n\n\nI would propose a slightly different workflow as well, which might\nmake this process lightly easier. Maybe you are already doing\nsomething like this, but I'll lay it out just in case.\n\nThe first step would be to create a 'to-be-publicly-released' branch\nwithin the secret repository, starting from the head of the original\npublic repository. Rebase all non-secret work to this branch, and\norganise it in whatever fashion necessary. This could be, for example,\none single commit representing the sum of all non-secret changes, or\nit could be an approximation of the actual history of these changes.\n\nOnce this branch has been prepared, you can verify that it branched\nfrom the public repository and that it contains no secret information\nusing standard git tools or even a patch view of the entire branch.\nYou can even add a signed tag to the branch once verified to record\nwho is verifying these changes, and ensuring nothing else gets added\nby someone else.\n\nThen you can use 'git bundle fromVerifiedTag.bundle\nverifiedTag..public/master' to create a bundle containing just those\ncommits on the release branch and their associated objects. You can\nverify what was included using 'git bundle list-heads\nfromVerifiedTag.bundle' to verify what was included.\n\nPerhaps there is a further need to look into the packed objects to\nverify nothing else is included, but this workflow should provide more\nconfidence in the bundled objects in the first place. As for actually\nverifying the bundled data after the bundle, I don't know so you would\nhave to look to the other answers.\n\nRegards,\n\nAndrew Ardill\n"}]}