-1

I have a GIT repo with code which has files with sensitive information inside them. This repo never meant to be public, until now.

Main question: How to make this repo public without files with sensitive information, but keeping it able to receive updates?

Private files enter image description here

Public files enter image description here

My idea was somehow to organise this: I will have two remotes for same repo. One for public, another for myself - private.

When I work, I checkout the private with all the files including ones with sensitive information.

When I need to publish the update, I checkout the public, merge changes from my private (except files with sensitive information) and push the changes back to public repo.

Is this possible at all?

ezik
  • 451
  • 1
  • 4
  • 15
  • 2
    Would it be possible to remove the sensitive information from the repository using something like environment? This seems trying to solve the wrong problem – MaartenDev Jun 20 '21 at 12:02
  • 1
    If you push something to a git remote, it will push the entire history of that branch/commit. This includes old versions of sensitive files or other branches that have been merged into the pushed branch. – dan1st Jun 20 '21 at 12:25
  • 2
    You say you "have developed a working solution", but all you actually have right now is an idea for a solution, that you don't know how to actually implement. Although configuration management is not an easy problem, there are many solutions out there which *are* actually fully implemented, so you're probably better off using one of those. – IMSoP Jun 20 '21 at 12:27
  • 1
    Would it be an option to complete remove the sensitive data from the repository (requiring everyone to re-clone it) and ignoring the sensitive files. You could e.g. use a script that downloads the sensitive data from an internal server (that just contains the secrets, not the repository). – dan1st Jun 20 '21 at 12:28
  • @MaartenDev It's kinda' built into the code. It's "content" of the html blocks. Plus it was already committed. – ezik Jun 20 '21 at 21:02
  • @IMSoP I think u did not get the point. Working solution is my "App", now I want to share the App with others, but when I started building it I never thought that might be the case. It was meant to be always private, but I accidentally built solution that others found useful. – ezik Jun 20 '21 at 21:04
  • @dan1st Yes, but how to do it and satisfy other requirements I mentioned in question. – ezik Jun 20 '21 at 21:11
  • What other requirements? – dan1st Jun 20 '21 at 21:14
  • @dan1st I'll rewrite my question and make it more clear, I feel it is badly formulated. – ezik Jun 20 '21 at 21:16

1 Answers1

2

Good approach is to keep sensitive data in separate configuration files, that not will be included in code repository. If you want, you can keep it in separate secured repo. The changes of these files should be done at release stage of your CD pipeline.

If you want to erase sensitive data from git history, you should do a app using libgit2, and create separate branch with the same commits, but with changed trees (omit the sensitive files), you should remember that the sha of commits will be changed, and you should keep in mind that parent part of commit info should be changed too. As @dan1st said, there are already written tools: filter-repo and filter-branch.

Leszek Mazur
  • 2,443
  • 1
  • 14
  • 28
  • 1
    libgit2 seems like a bit of an overkill. [`filter-repo` or `filter-branch` might be easier to use](https://stackoverflow.com/q/872565/10871900). – dan1st Jun 20 '21 at 21:15