@@ -24,8 +24,8 @@ Minor version changes will not break compatibility between the previous minor ve
24
24
We expect to release patches for minor releases, so we create a patch trunk to branch from. The naming convention follows "v2.1.x", where the major version is 2, minor is 1, and "x" is a patch version placeholder.
25
25
26
26
``` bash
27
- $ MAV_MIN_VER= " v ${MAJOR_VERSION} .${NEW_MINOR_VERSION} "
28
- $ git checkout -b " ${MAJ_MIN_VER} .x" tags/" v${MAJ_MIN_VER} .0"
27
+ $ export MAJ_MIN_VER= " ${MAJOR_VERSION} .${NEW_MINOR_VERSION} "
28
+ $ git checkout -b " v ${MAJ_MIN_VER} .x" tags/" v${MAJ_MIN_VER} .0"
29
29
$ git push
[email protected] :operator-framework/operator-sdk.git
" v${MAJ_MIN_VER} .x"
30
30
```
31
31
@@ -116,9 +116,64 @@ Patch releases should have the following format:
116
116
...
117
117
```
118
118
119
+ # Release Signing
120
+
121
+ When a new release is created, the tag for the commit it signed with a maintainer's gpg key and
122
+ the binaries for the release are also signed by the same key. All keys used by maintainers will
123
+ be available via public gpg keyservers such as [ pgp.mit.edu] [ mit-keyserver ] . To verify a git
124
+ tag signature, use this command:
125
+
126
+ ``` sh
127
+ $ git verify-tag --verbose ${TAG_NAME}
128
+ ```
129
+
130
+ To verify a release binary using the provided asc files, place the binary and corresponding asc
131
+ file into the same directory and use the corresponding command:
132
+
133
+ ``` sh
134
+ # macOS
135
+ $ gpg --verify operator-sdk-${RELEASE_VERSION} -x86_64-apple-darwin.asc
136
+ # GNU/Linux
137
+ $ gpg --verify operator-sdk-${RELEASE_VERSION} -x86_64-linux-gnu.asc
138
+ ```
139
+
140
+ If you do not have the maintainers public key on your machine, you will get an error message similar
141
+ to this:
142
+
143
+ ``` sh
144
+ $ git verify-tag ${TAG_NAME}
145
+ gpg: Signature made Wed 31 Oct 2018 02:57:31 PM PDT
146
+ gpg: using RSA key 4AEE18F83AFDEB23
147
+ gpg: Can' t check signature: public key not found
148
+ ```
149
+
150
+ To download the key, use this command, replacing `${KEY_ID}` with the RSA key string provided in the output
151
+ of the previous command:
152
+
153
+ ```sh
154
+ $ gpg --recv-key ${KEY_ID}
155
+ ```
156
+
157
+ Now you should be able to verify the tags and/or binaries
158
+
159
+ ## For maintainers
160
+ For new maintainers who have not done a release and do not have their gpg key on a public
161
+ keyserver, you must add your public key to a keyserver. To do this, output your armored
162
+ public key using this command:
163
+
164
+ ```sh
165
+ $ gpg --armor --export ${GPG_EMAIL} > mykey.asc
166
+ ```
167
+
168
+ Then, copy and paste the content of the outputted file into the `Submit a key` section on
169
+ the [MIT PGP Public Key Server][mit-keyserver] or any other public keyserver that forwards
170
+ the key to other public keyservers. Once that is done, other people can download your public
171
+ key and you are ready to sign releases.
172
+
119
173
[link-semver]:https://semver.org/
120
174
[link-github-milestones]: https://help.github.com/articles/about-milestones/
121
175
[doc-maintainers]:../MAINTAINERS
122
176
[link-github-gpg-key-upload]:https://github.com/settings/keys
123
177
[link-git-config-gpg-key]:https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
124
- [ doc-kube-version ] :https://github.com/operator-framework/operator-sdk#prerequisites
178
+ [doc-kube-version]:https://github.com/operator-framework/operator-sdk#prerequisites
179
+ [mit-keyserver]:https://pgp.mit.edu
0 commit comments