1GIT-SECRET(7) git-secret 0.5.0-alpha2 GIT-SECRET(7)
2
3
4
6 git-secret - bash tool to store private data inside a git repo.
7
9 These steps cover the basic process of using git-secret to specify
10 users and files that will interact with git-secret, and to encrypt and
11 decrypt secrets.
12
13 1. Before starting, make sure you have created a gpg RSA key-pair:
14 which are a public key and a secret key pair, identified by your
15 email address and stored with your gpg configuration. Generally
16 this gpg configuration and keys will be stored somewhere in your
17 home directory.
18
19 2. Begin with an existing or new git repository.
20
21 3. Initialize the git-secret repository by running git secret init.
22 The .gitsecret/ folder will be created, with subdirectories keys/
23 and paths/, .gitsecret/keys/random_seed will be added to .gitig‐
24 nore, and .gitignore will be configured to not ignore .secret
25 files.
26
27
28
29 Note all the contents of the .gitsecret/ folder should be checked in,
30 /except/ the random_seed file. This also means that of all the files in
31 .gitsecret/, only the random_seed file should be mentioned in your
32 .gitignore file.
33
34 1. Add the first user to the git-secret repo keyring by running git
35 secret tell your@email.id.
36
37 2. Now it´s time to add files you wish to encrypt inside the git-se‐
38 cret repository. This can be done by running git secret add <file‐
39 names...> command, which will also (as of 0.2.6) add entries to
40 .gitignore, stopping those files from being be added or committed
41 to the repo unencrypted.
42
43 3. Then run git secret hide to encrypt the files you added with git
44 secret add. The files will be encrypted with the public keys in
45 your git-secret repo´s keyring, each corresponding to a user´s
46 email that you used with tell.
47
48
49
50 After using git secret hide to encrypt your data, it is safe to commit
51 your changes. NOTE: It´s recommended to add the git secret hide command
52 to your pre-commit hook, so you won´t miss any changes.
53
54 1. Later you can decrypt files with the git secret reveal command, or
55 print their contents to stdout with the git secret cat command. If
56 you used a password on your GPG key (always recommended), it will
57 ask you for your password. And you´re done!
58
59
60
61 Usage: Adding someone to a repository using git-secret
62 1. Get their gpg public-key. You won´t need their secret key. They can
63 export their public key for you using a command like:
64
65
66
67 gpg --armor --export their@email.com > public_key.txt # armor here
68 makes it ascii
69
70 1. Import this key into your gpg keyring (in ~/.gnupg or similar) by
71 running gpg --import public_key.txt
72
73 2. Now add this person to your secrets repo by running git secret tell
74 their@email.id (this will be the email address associated with
75 their public key)
76
77 3. Now remove the other user´s public key from your personal keyring
78 with gpg --delete-keys their@email.id
79
80 4. The newly added user cannot yet read the encrypted files. Now,
81 re-encrypt the files using git secret reveal; git secret hide -d,
82 and then commit and push the newly encrypted files. (The -d options
83 deletes the unencrypted file after re-encrypting it). Now the newly
84 added user will be able to decrypt the files in the repo using
85 git-secret reveal.
86
87
88
89 Note that when you first add a user to a git-secret repo, they will not
90 be able to decrypt existing files until another user re-encrypts the
91 files with the new keyring.
92
93 If you do not want unexpected keys added, you can configure some
94 server-side security policy with the pre-receive hook.
95
96 Using gpg
97 You can follow a quick gpg tutorial at devdungeon https://www.devdun‐
98 geon.com/content/gpg-tutorial. Here are the most useful commands to get
99 started:
100
101 To generate a RSA key-pair, run:
102
103
104
105 gpg --gen-key
106
107
108
109 To export your public key, run:
110
111
112
113 gpg --armor --export your.email@address.com > public-key.gpg
114
115
116
117 To import the public key of someone else (to share the secret with them
118 for instance), run:
119
120
121
122 gpg --import public-key.gpg
123
124
125
126 To make sure you get the original public keys of the indicated persons,
127 be sure to use a secure channel to transfer it, or use a service you
128 trust, preferably one that uses encryption such as Keybase, to retrieve
129 their public key. Otherwise you could grant the wrong person access to
130 your secrets by mistake!
131
132 Using git-secret for Continuous Integration / Continuous Deployment (CI/CD)
133 When using git-secret for CI/CD, you get the benefit that any deploy‐
134 ment is necessarily done with the correct configuration, since it is
135 collocated with the changes in your code.
136
137 One way of doing it is the following:
138
139 1. create a gpg key for your CI/CD environment. You can chose any name
140 and email address you want: for instance MyApp Example <myapp@exam‐
141 ple.com> if your app is called MyApp and your CI/CD provider is Ex‐
142 ample. It is easier not to define a passphrase for that key. How‐
143 ever, if defining a passphrase is unavoidable, use a unique
144 passphrase for the private key.
145
146 2. run gpg --armor --export-secret-key myapp@example.com to get your
147 private key value
148
149 3. Create an env var on your CI/CD server GPG_PRIVATE_KEY and assign
150 it the private key value. If a passphrase has been setup for the
151 private key, create another env var on the CI/CD server
152 GPG_PASSPHRASE and assign it the passphrase of the private key.
153
154 4. Then write your Continuous Deployment build script. For instance:
155
156
157
158
159
160 # As the first step: install git-secret,
161 # see: https://git-secret.io/installation
162
163 # Create private key file
164 echo "$GPG_PRIVATE_KEY" > ./private_key.gpg
165 # Import private key and avoid the "Inappropriate ioctl for device" error
166 gpg --batch --yes --pinentry-mode loopback --import private_key.gpg
167 # Reveal secrets without user interaction and with passphrase. If no passphrase
168 # is created for the key, remove `-p $GPG_PASSPHRASE`
169 git secret reveal -p "$GPG_PASSPHRASE"
170 # carry on with your build script, secret files are available ...
171
172
173
174 Note: your CI/CD might not allow you to create a multiline value. In
175 that case, you can export it on one line with
176
177
178
179 gpg --armor --export-secret-key myapp@example.com | tr ´\n´ ´,´
180
181
182
183 You can then create your private key file with:
184
185
186
187 echo "$GPG_PRIVATE_KEY" | tr ´,´ ´\n´ > ./private_key.gpg
188
189
190
191 Also note: the gpg version on the CI/CD server MUST INTEROPERATE with
192 the one used locally. Otherwise, gpg decryption can fail, which leads
193 to git secret reveal reporting cannot find decrypted version of file
194 error. The best way to ensure this is to use the same version of gnupg
195 on different systems.
196
198 You can configure the version of gpg used, or the extension your en‐
199 crypted files use, to suit your workflow better. To do so, just set the
200 required variable to the value you need. This can be done in your shell
201 environment file or with each git-secret command. See below, or the man
202 page of git-secret for an explanation of the environment variables
203 git-secret uses.
204
205 The settings available to be changed are:
206
207 • $SECRETS_VERBOSE - sets the verbose flag to on for all git-secret
208 commands; is identical to using -v on each command that supports
209 it.
210
211 • $SECRETS_GPG_COMMAND - sets the gpg alternatives, defaults to gpg.
212 It can be changed to gpg, gpg2, pgp, /usr/local/gpg or any other
213 value. After doing so rerun the tests to be sure that it won´t
214 break anything. Tested with gpg and gpg2.
215
216 • $SECRETS_GPG_ARMOR - sets the gpg --armor mode
217 https://www.gnupg.org/gph/en/manual/r1290.html. Can be set to 1 to
218 store secrets file as text. By default is 0 and store files as bi‐
219 naries.
220
221 • $SECRETS_EXTENSION - sets the secret files extension, defaults to
222 .secret. It can be changed to any valid file extension.
223
224 • $SECRETS_DIR - sets the directory where git-secret stores its
225 files, defaults to .gitsecret. It can be changed to any valid di‐
226 rectory name.
227
228 • $SECRETS_PINENTRY - allows user to specify a setting for gpg´s
229 --pinentry option. See gpg docs https://github.com/gpg/pinentry for
230 details about gpg´s --pinentry option.
231
232
233
235 CRETS_DIR</code>)
236 This folder contains information about the files encrypted by git-se‐
237 cret, and about which public/private key sets can access the encrypted
238 data.
239
240 You can change the name of this directory using the SECRETS_DIR envi‐
241 ronment variable.
242
243 Use the various git-secret commands to manipulate the files in .gitse‐
244 cret, you should not change the data in these files directly.
245
246 Exactly which files exist in the .gitsecret folder and what their con‐
247 tents are vary slightly across different versions of gpg. Also, some
248 versions of gpg might not work well with keyrings created or modified
249 with newer versions of gpg. Thus it is best to use git-secret with the
250 same version of gpg being used by all users. This can be forced by in‐
251 stalling matching versions of gpg and using SECRETS_GPG_COMMAND envi‐
252 ronment variable.
253
254 For example, there is an issue between gpg version 2.1.20 and later
255 versions which can cause problems reading and writing keyring files be‐
256 tween systems (this shows up in errors like ´gpg: skipped packet of
257 type 12 in keybox´).
258
259 This is not the only issue it is possible to encounter sharing files
260 between different versions of gpg. Generally you are most likely to en‐
261 counter issues between gpg versions if you use git-secret tell or
262 git-secret removeperson to modify your repo´s git-secret keyring using
263 a newer version of gpg, and then try to operate on that keyring using
264 an older version of gpg.
265
266 The git-secret internal data is separated into two directories:
267
268 <code>.gitsecret/paths</code>
269 This directory currently contains only the file mapping.cfg, which
270 lists all the files your storing encrypted. In other words, the path
271 mappings: what files are tracked to be hidden and revealed.
272
273 All the other internal data is stored in the directory:
274
275 <code>.gitsecret/keys</code>
276 This directory contains data used by git-secret and gpg to encrypt
277 files to be accessed by the permitted users.
278
279 In particular, this directory contains a gnupg keyring with public keys
280 for the emails used with tell.
281
282 This is the keyring used to encrypt files with git-secret-hide.
283
284 git-secret-reveal and git-secret-cat, which decrypt secrets, instead
285 use the user´s private keys (which probably reside somewhere like
286 ~/.gnupg/). Note that user´s private keys, needed for decryption, are
287 not in the .gitsecret/keys directory.
288
289 Generally speaking, all the files in this directory except random_seed
290 should be checked into your repo. By default, git secret init will add
291 the file .gitsecret/keys/random_seed to your .gitignore file.
292
293 Again, you can change the name of this directory using the SECRETS_DIR
294 environment variable.
295
296
297
298sobolevn April 2022 GIT-SECRET(7)