summaryrefslogtreecommitdiffstats
path: root/dev/archive/signing.mdwn
blob: a74a43089b096908cfdb3191dcad9046a191628e (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
[[!meta title="Package Archive Signing"]]

Background
==========

Package archive signing will enable verification of package archive index files
and establish a chain of trust (through `SHA256sum` fields) to verify individual
packages.  It will allow ProteanOS's package management tools to more securely
retrieve packages from the archive.

Implementation
==============

ProteanOS Archive Manager
-------------------------

[[pro-archman|dev/pro-archman]] will gain a new option: an archive signing key.
If a key is provided, pro-archman will run `gpg` to sign, with the specified
key, `Packages` feed index files when generated.

A `gpg` executable will be an optional dependency, found by the `configure`
script at build time.

ProteanOS Development Kit
-------------------------

[[prokit|dev/prokit]] will verify package feed index files with `gpg` if
configured in the profile, and the `proteanos` profile will enable such
verification.

A `gpg` executable will be an optional dependency, found by the `configure`
script at build time.

A keyring (or ASCII-armored keys that are added to a keyring at either build
time or run time) associated with the profile should probably be included with
prokit.  Otherwise, a user would need to manually import the archive signing
key(s) into their keyring.

If keys are distributed with prokit, **revocations and key transitions need to
be handled somehow**.

New keys can be distributed with new versions of prokit, though this would
require users to upgrade prokit to get new keys.  Revocations, being more of a
security risk that can go unnoticed by users, would need to be more actively and
immediately received by users.  prokit could perhaps check a key server (over
HKPS) each time before using a key.

And if prokit needs to check key servers anyway, it could also use them to find
new archive signing keys, as long as at least one "seed" key is distributed with
prokit.  prokit should find and use only archive signing keys (by a user ID
specified in the profile) that are signed by a non-revoked previous key (or a
signed chain of keys with the user ID).

A user already has to import a key into their own keyring to verify their prokit
download.  Maybe it's better to just instruct users to also download the archive
signing key(s) into their keyrings.  This takes advantage of existing PKI, and
leaves users to make sure their keyring is kept updated with signatures,
revocations, changed expiration dates, and transitions.  It also avoids having
released prokit versions "expire" due to included keys expiring.

Suggestions welcome.

Opkg
----

The opkg package manager supports verifying package feeds.  This feature
requires linking against the [GnuPG Made Easy (GPGME) library][gpgme].

ProteanOS packages for GPGME and its dependencies need to be prepared and
uploaded.  gpgme depends on libgpg-error (packaged and uploaded) and libassuan.
Its testsuite depends on gnupg.  gnupg in turn depends on libgpg-error,
libgcrypt, libassuan, libksba, and npth.  libgcrypt depends on libgpg-error.
Below is a DOT-language digraph representation of these dependencies that can be
rendered with Graphviz.

Once gpgme and its dependencies are packaged in ProteanOS, opkg can be built
with package feed verification.  This feature should be optional.  The `opkg`
source package should have two builds, with and without verification enabled.
This will probably mean generating new binary packages `opkg-gpg` and
`libopkg.1-gpg` (which will conflict with `opkg` and `libopkg.1` respectively)
and installing data files into binary package directories without the aid of
`oh-installfiles`.  Although, option 1 of the [[static_libopkg|pkg/opkg/static]]
plan would simplify this by getting rid of the `libopkg.1` and `libopkg.1-dev`
packages altogether.  The `opkg` source package could then build just `opkg`,
`opkg-gpg`, `opkg-dbg`, and `opkg-doc` binary packages.

Archive Keyring
---------------

The package archive keyring will need to be maintained in a ProteanOS package.


GPGME Dependencies
==================

As noted above, gpgme depends on various packages.  Following is the
DOT-language dependency graph (which can be rendered as a PNG image with the
command pipeline in the header comment, if saved as `gpgme.dot`):

    /*
     * Dependencies of GPGME
     *
     * Render by running:
     *   ccomps -x gpgme.dot | dot | gvpack | neato -n2 -Tpng -ogpgme.png
     */
    
    digraph deps {
    	graph [fontname="FreeSans"];
    	node [fontname="FreeSans"];
    	edge [fontname="FreeSans"];
    
    	subgraph cluster_gpgme {
    		style = filled;
    		color = "#0093dd";
    		node [style=filled];
    		label = "gpgme";
    
    		"gpgme" [color=red];
    		"libgpg-error" [color=green];
    		"libassuan" [color=red];
    		"gnupg" [color=red];
    		"libgcrypt" [color=red];
    		"libksba" [color=red];
    		"npth" [color=red];
    	}
    
    	"gpgme" -> "libgpg-error";
    	"gpgme" -> "libassuan";
    	"gpgme" -> "gnupg" [color=gray,label="testsuite"];
    	"gnupg" -> "libgpg-error";
    	"gnupg" -> "libgcrypt";
    	"gnupg" -> "libassuan";
    	"gnupg" -> "libksba";
    	"gnupg" -> "npth";
    	"libgcrypt" -> "libgpg-error";
    }

[gpgme]: https://www.gnupg.org/software/gpgme/index.html