ReleasesKey » History » Version 1
Denis 'GNUtoo' Carikli, 04/04/2020 11:20 AM
|1||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.
h2. Long term Replicant key
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.
h2. Contributor keys
h2. Long term
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.