Usage: Adding someone to a repository using git-secret

1.

Get their gpg public-key. You won´t need their secret key. They can export their public key for you using a command like:

gpg --armor --export their@email.com > public_key.txt # armor here makes it ascii

1.

Import this key into your gpg keyring (in ~/.gnupg or similar) by running gpg --import public_key.txt

2.

Now add this person to your secrets repo by running git secret tell their@email.id (this will be the email address associated with their public key)

3.

Now remove the other user´s public key from your personal keyring with gpg --delete-keys their@email.id

4.

The newly added user cannot yet read the encrypted files. Now, re-encrypt the files using git secret reveal; git secret hide -d, and then commit and push the newly encrypted files. (The -d options deletes the unencrypted file after re-encrypting it). Now the newly added user will be able to decrypt the files in the repo using git-secret reveal.

Note that when you first add a user to a git-secret repo, they will not be able to decrypt existing files until another user re-encrypts the files with the new keyring.

If you do not want unexpected keys added, you can configure some server-side security policy with the pre-receive hook.

Using gpg

You can follow a quick gpg tutorial at devdungeon https://www.devdungeon.com/content/gpg-tutorial. Here are the most useful commands to get started:

To generate a RSA key-pair, run:

gpg --gen-key

To export your public key, run:

gpg --armor --export your.email@address.com > public-key.gpg

To import the public key of someone else (to share the secret with them for instance), run:

gpg --import public-key.gpg

To make sure you get the original public keys of the indicated persons, be sure to use a secure channel to transfer it, or use a service you trust, preferably one that uses encryption such as Keybase, to retrieve their public key. Otherwise you could grant the wrong person access to your secrets by mistake!

Using git-secret for Continuous Integration / Continuous Deployment (CI/CD)

When using git-secret for CI/CD, you get the benefit that any deployment is necessarily done with the correct configuration, since it is collocated with the changes in your code.

One way of doing it is the following:

1.

create a gpg key for your CI/CD environment. You can chose any name and email address you want: for instance MyApp Example <myapp@example.com> if your app is called MyApp and your CI/CD provider is Example. It is easier not to define a passphrase for that key. However, if defining a passphrase is unavoidable, use a unique passphrase for the private key.

2.

run gpg --armor --export-secret-key myapp@example.com to get your private key value

3.

Create an env var on your CI/CD server GPG_PRIVATE_KEY and assign it the private key value. If a passphrase has been setup for the private key, create another env var on the CI/CD server GPG_PASSPHRASE and assign it the passphrase of the private key.

4.

Then write your Continuous Deployment build script. For instance:

# As the first step: install git-secret,
# see: https://git-secret.io/installation
# Create private key file
echo "$GPG_PRIVATE_KEY" > ./private_key.gpg
# Import private key and avoid the "Inappropriate ioctl for device" error
gpg --batch --yes --pinentry-mode loopback --import private_key.gpg
# Reveal secrets without user interaction and with passphrase. If no passphrase
# is created for the key, remove `-p $GPG_PASSPHRASE`
git secret reveal -p "$GPG_PASSPHRASE"
# carry on with your build script, secret files are available ...

Note: your CI/CD might not allow you to create a multiline value. In that case, you can export it on one line with

gpg --armor --export-secret-key myapp@example.com | tr ´\n´ ´,´

You can then create your private key file with:

echo "$GPG_PRIVATE_KEY" | tr ´,´ ´\n´ > ./private_key.gpg

Also note: the gpg version on the CI/CD server MUST INTEROPERATE with the one used locally. Otherwise, gpg decryption can fail, which leads to git secret reveal reporting cannot find decrypted version of file error. The best way to ensure this is to use the same version of gnupg on different systems.

<code>.gitsecret/paths</code>

This directory currently contains only the file mapping.cfg, which lists all the files your storing encrypted. In other words, the path mappings: what files are tracked to be hidden and revealed.

All the other internal data is stored in the directory:

<code>.gitsecret/keys</code>

This directory contains data used by git-secret and gpg to encrypt files to be accessed by the permitted users.

In particular, this directory contains a gnupg keyring with public keys for the emails used with tell.

This is the keyring used to encrypt files with git-secret-hide.

git-secret-reveal and git-secret-cat, which decrypt secrets, instead use the user´s private keys (which probably reside somewhere like ~/.gnupg/). Note that user´s private keys, needed for decryption, are not in the .gitsecret/keys directory.

Generally speaking, all the files in this directory except random_seed should be checked into your repo. By default, git secret init will add the file .gitsecret/keys/random_seed to your .gitignore file.

Again, you can change the name of this directory using the SECRETS_DIR environment variable.