ReleasesKey » History » Version 11

dl lud, 07/01/2020 02:31 AM
Fix typos.

1 1 Denis 'GNUtoo' Carikli
h1. ReleasesKey
3 9 Denis 'GNUtoo' Carikli
h2. Design goals
7 1 Denis 'GNUtoo' Carikli
We need to make sure that users are able to easily check the signature with as few steps as possible, else they would simply skip the signature checking as it's too complicated.
9 9 Denis 'GNUtoo' Carikli
h2. Signature schemes
10 1 Denis 'GNUtoo' Carikli
11 9 Denis 'GNUtoo' Carikli
h3. Long term Replicant key
13 1 Denis 'GNUtoo' Carikli
The issue with having a long term Replicant key is that it's difficult to make good tradeoffs:
* As developers making releases changes, the key would need to be passed around. This has several issues:
** Developers having the key might not be reachable anymore.
** It increase the probability of having security issues:
*** The key has to be passed around, and mistakes can happen
*** The number of people with access to the key increase over time:
**** Decades after, former developers could be facing situations where they are forced to hand over the key.
**** People can also change over time
It may be possible to limit some of the impact by using the gpg key as a PKI: It's possible to have some people have a separate primary key, while handing over subkeys to other people, but it doesn't completely solve any of the issues above, as they would all still apply to the people having access to the primary key, and only remove the subkeys of the equation.
24 9 Denis 'GNUtoo' Carikli
h3. Contributor keys
25 2 Denis 'GNUtoo' Carikli
This is what is in use at the time of writing.
27 3 Denis 'GNUtoo' Carikli
29 1 Denis 'GNUtoo' Carikli
* Users have to trust developers signing Replicant images. So the advantage is that developers can change, and even work on different Android versions.
30 11 dl lud
* The issue is that contributors tend to use the same key for signing Replicant images and other usages (like mails, etc). That is good as it enables users to more easily check the key, but in the other hand both uses case might conflict at some point. For instance it might be a good idea to have ephemeral signing subkeys and short expiration dates. But for Replicant images, it's better to have longer term signatures.
31 2 Denis 'GNUtoo' Carikli
32 9 Denis 'GNUtoo' Carikli
h3. Long term
33 1 Denis 'GNUtoo' Carikli
At the time of writing, the Replicant images tend to be relevant for a very long time (years).
For instance The GTA04 A4 is supported by Replicant 4.2 but not by Replicant 6.0, and in order to maintain support for some devices in libsamsung-ipc we also need to build and test Replicant 4.2 images, many years after. While old images do have many security issues, some people don't care much as other distributions probably have other issues like backdoors and freedom issues.
Having the ability to easily run Replicant 4.2 years later was also very useful to solve the bug about SIM card not being recognized.
So it's still good to make sure that everyone can easily check the signature of old releases.
* If the primary key of a gpg key is not used to sign the images, like for the Replicant 6.0 0004 RC1, the subkeys have to be kept for as long as possible and not discarded unless they never expire. If they never expire it could be possible to generate a key just for signing the image and discard the private part of that key right after. It might even still be possible to somehow revoke that key if people update their keyring, but it would not be possible to sign new images with it.
* If the keys or the subkeys do expire at some point (which is a good practice in case you loose your key), then the image verification will fail.
46 9 Denis 'GNUtoo' Carikli
h3. Keyring
47 4 Denis 'GNUtoo' Carikli
Parabola uses a keyring to check the package. 
50 1 Denis 'GNUtoo' Carikli
51 4 Denis 'GNUtoo' Carikli
* It enables multiple developers to sign packages without having to share a key.
52 8 Denis 'GNUtoo' Carikli
* It works well when it's shipped by the distribution you use. It would need a tool to check Replicant images anyway.
53 4 Denis 'GNUtoo' Carikli
* We might not be able to ship a Replicant keyring in each GNU/Linux distribution.
54 2 Denis 'GNUtoo' Carikli
55 9 Denis 'GNUtoo' Carikli
h3. Signify
56 5 Denis 'GNUtoo' Carikli
57 1 Denis 'GNUtoo' Carikli
OpenBSD uses signify.
58 5 Denis 'GNUtoo' Carikli
59 1 Denis 'GNUtoo' Carikli
* The fact that the key are ephemeral and from an OpenBSD version, you will be able to check the next one, but not the one after is very secure and very simple to get it right too.
61 5 Denis 'GNUtoo' Carikli
* Replicant images are longer term than OpenBSD releases. We would also need to ship the public keys in various GNU/Linux distributions.
63 9 Denis 'GNUtoo' Carikli
h3. Specific tool
64 5 Denis 'GNUtoo' Carikli
65 9 Denis 'GNUtoo' Carikli
The tool could use other schemes, like something similar to signify or a keyring.
67 5 Denis 'GNUtoo' Carikli
68 1 Denis 'GNUtoo' Carikli
* Would suit our needs perfectly
* Would need to be shipped in every GNU/Linux distribution
Such tool could for instance check signatures of an image, and even identify the Replicant version of the image.
Rockbox managed to ship an installer in many GNU/Linux distributions, so if we ever make a dedicated tool, it would be interesting to have the ability to easily install Replicant from that tool.
74 9 Denis 'GNUtoo' Carikli
h2. Applications
Schemes could also be combined.
79 10 Denis 'GNUtoo' Carikli
So far we have the following install flow: Recovery signature -> Recovery -> zip
80 9 Denis 'GNUtoo' Carikli
81 10 Denis 'GNUtoo' Carikli
The users check the recovery signature, and the recovery then check the zip. 
82 9 Denis 'GNUtoo' Carikli
83 11 dl lud
The recovery could be signed with a Replicant contributor key, while it could check the signatures of the zip through a keyring for instance.