How do you handle sensitive data in a public git r

问题:

How do you handle sensitive data like secret API keys, hash salts when you keep your code in a public git repo?

Obviously keeping the sensitive data in the code will compromise it.

Another solution is to not hardcode the secret info in the code, but store it in a stand-alone file and gitignore the file. This has the disadvantage that when someone pulls your code for the first time the secret information will be missing and it won't run out of the box. This can be accounted for by writing a "initialize if missing" routine in the code, but then you're letting the git system slip into your code, which is IMO not a good thing.

And another solution is making a "default" secret information file, commit it at the start of the project and then use your own information without committing it. But this may make git complain that you have un-commited changes when you pull.

So what is the common way to handle this?

回答1:

Try to use .gitattributes for path with configured encryption/decryption filter:

*secure.yml filter=crypt

And in the .git/config add the configuration for crypt filter:

[filter "crypt"]
    clean = openssl enc ...
    smudge = openssl enc -d ...
    required

回答2:

Arguably you shouldn't hardcode these properties into your source, since an administrator will want the option to change them on a given system. If these properties are in a properties file (e.g. in your home directory) the problem is solved.

For users that might run into trouble you can check in a defaults file that they can copy to their home folder and modify. If the error messages and README are clear on the subject of missing this particular file this setup will work quite well.

回答3:

The best solution would be a private git submodule and a public git repository.

See this quesiton for more information; a nice quote for you:

When you exclude or ignore you are just keeping files from being added to your repository. none of the 'sensitive files' files are even in the repository, just in your working directory.

回答4:

If someone need for their Android project, there is the simplest way I find:

step 1: create: res/values/secrets.xml with:

<!-- Inside of `res/values/secrets.xml` -->
<?xml version="1.0" encoding="utf-8"?>
<resources>
    <string name="parse_application_id">xxxxxx</string>
    <string name="parse_client_secret">yyyyyy</string>
    <string name="google_maps_api_key">zzzzzz</string>
</resources>

step 2: use it in code or xml file

getString(R.string.parse_application_id),
getString(R.string.parse_client_secret)

or

<meta-data
    android:name="com.google.android.maps.v2.API_KEY"
    android:value="@string/google_maps_api_key"/>

step 3: add this line into .gitignore file

 **/*/res/values/secrets.xml

here is the full article

回答5:

The "default" secret information file is a good idea, however, there is no way to avoid the git warnings, even if you ignore the file. From the github help page:

git will not ignore a file that was already tracked before a rule was added to this file to ignore it. In such a case the file must be un-tracked, usually with git rm --cached filename

Therefore, adding a "dummy" or "default" file and then ignoring it won't prevent warnings. While the approach will work, it will be inconvenient as you will always have to manually exclude the sensitive file from every commit.

Untracking the file removes it from github, which defeats the purpose of having the file in the first place.

Perhaps the submodule suggestion will work.