aboutsummaryrefslogtreecommitdiff
path: root/bpkg/repository-signing.cli
blob: 1b73fc234821a887fb1196718cab28d3c0cea678 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
// file      : bpkg/repository-signing.cli
// copyright : Copyright (c) 2014-2017 Code Synthesis Ltd
// license   : MIT; see accompanying LICENSE file

include <bpkg/common-options.hxx>;

"\section=1"
"\name=bpkg-repository-signing"
"\summary=how to sign repository"

"
\h|SYNOPSIS|

\c{\b{bpkg rep-create --key} ...}

\h|DESCRIPTION|

The purpose of signing a repository is to prevent tampering with packages
either during transmission or on the repository \i{host machine}. Ideally,
you would generate and sign the repository manifests on a separate
\i{build machine} that is behind a firewall. This way, if (or, really,
when) your host machine is compromised, it will be difficult for an attacker
to compromise the repository packages without being noticed. Since the
repository key is kept on the build machine (or, better yet, on a \i{one-way}
PIV/PKCS#11 device; see below) they will not be able to re-sign the modified
repository.

\cb{bpkg} uses X.509 public key cryptography for repository signing.
Currently, only the explicit \i{first use} certificate authentication is
implemented.  That is, for an unknown (to this \cb{bpkg} configuration)
repository certificate its subject information and fingerprint are presented
to the user. If the user confirms the authenticity of the certificate, then it
is added to the configuration and any repository that in the future presents
this certificate is trusted without further confirmations, provided its name
matches the certificate's subject (see below). In the future a certificate
authority (CA)-based model may be added.

The rest of this guide shows how to create a key/certificate pair for
\cb{bpkg} repository signing and use it to sign a repository. At the end it
also briefly explains how to store the private key on a PIV/PKCS#11 device
using Yubikey 4 as an example.

\dl|

\li|1. Generate Private Key\n

The first step is to generate the private key:

\
$ openssl genrsa -aes256 2048 >key.pem
\

If you would like to generate a key without password protection (not a good
idea except for testing), leave the \cb{-aes256} option out. You may also need
to add \cb{-nodes} depending on your \cb{openssl(1)} configuration.
|

\li|\n2. Generate Certificate\n

Next create the certificate configuration file by saving the following into
\cb{cert.conf}. You may want to keep it around in case you need to renew an
expired certificate, etc.

\
name  = example.com
org   = Example, Inc
email = admin@example.com

[req]
distinguished_name = req_distinguished_name
x509_extensions    = v3_req
prompt             = no
utf8               = yes

[req_distinguished_name]
O  = $org
CN = name:$name

[v3_req]
keyUsage         = critical,digitalSignature
extendedKeyUsage = critical,codeSigning
subjectAltName   = email:$email
\

Adjust the first three lines to match your details. If the repository is
hosted by an organization, use the organization's name for \cb{org}. If you
host it as an individual, put your full, real name there. Using any kind of
aliases or nicknames is a bad idea (except, again, for testing). Remember,
users of your repository will be presented with this information and if they
see it was signed by someone named SmellySnook, they will unlikely trust
it. Also use a working email address in case users need to contact you about
issues with your certificate.

The \cb{name} field is a canonical repository name prefix. Any repository with
a canonical name that starts with this prefix can be authenticated by this
certificate. For example, name \cb{example.com} will match any repository
hosted on \cb{{,www.,pkg.,bpkg.\}example.com}. While name
\cb{example.com/math} will match \cb{{...\}example.com/pkg/1/math} but not
\cb{{...\}example.com/pkg/1/misc}. See the repository manifest documentation
for more information on canonical names. Note also that the \cb{name:} prefix
in the \cb{CN} value is not a typo.

Once the configuration file is ready, generate the certificate:

\
openssl req -x509 -new -sha256 -key key.pem \
  -config cert.conf -days 730 >cert.pem
\

To verify the certificate information, run:

\
openssl x509 -noout -nameopt RFC2253,sep_multiline \
  -subject -dates -email <cert.pem
\

|

\li|\n3. Add Certificate to Repository\n

Add the \cb{certificate:} field for the base repository (\cb{role: base})
in the \cb{repositories} manifest file(s):

\
certificate: \
<cert>
\\
\

Replace \i{cert} with the entire contents of \cb{cert.pem} (including the
\c{BEGIN CERTIFICATE} and \c{END CERTIFICATE} lines). So you will have
an entry like this:

\
certificate: \
-----BEGIN CERTIFICATE-----
MIIDQjCCAiqgAwIBAgIJAIUgsIqSnesGMA0GCSqGSIb3DQEBCwUAMDkxFzAVBgNV
.
.
.
+NOVBamEvjn58ZcLfWh2oKee7ulIZg==
-----END CERTIFICATE-----
\\
\

|

\li|\n4. Sign Repository\n

When generating the repository manifests with the \l{bpkg-rep-create(1)}
command, specify the path to \cb{key.pem} with the \cb{--key} option:

\
bpkg rep-create --key /path/to/key.pem /path/to/repository
\

You will be prompted for a password to unlock the private key.
|

\li|\n5. Using PIV/PKCS#11 Device\n

This optional step shows how to load the private key into Yubikey 4 and then
use it instead of the private key itself for signing the repository. Note that
you will need OpenSSL 1.0.2 or later for the signing part to work.

First change the Yubikey MKEY, PUK, and PIN if necessary. You should
definitely do this if it still has the factory defaults. Then import the
private key and the certificate into Yubikey (replace \i{mkey} with the
management key):

\
yubico-piv-tool --key=<mkey> -a import-key -s 9c <key.pem
yubico-piv-tool --key=<mkey> -a import-certificate -s 9c <cert.pem
\

After this you will normally save the certificate/private key onto backup
media, store it in a secure, offline location, and remove the key from the
build machine.

To sign the repository with Yubikey specify the following options instead of
just \cb{--key} as at step 4 (\c{\"SIGN key\"} is the name for slot \c{9c}):

\
bpkg rep-create                                     \
  --openssl-option -engine --openssl-option pkcs11  \
  --openssl-option -keyform --openssl-option engine \
  --key \"label_SIGN key\" /path/to/repository
\

||
"