Design goals

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.

Signature schemes

Long term Replicant key

The issue with having a long term Replicant key is that it's difficult to make good tradeoffs:

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.

Contributor keys

This is what is in use at the time of writing.


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.



Parabola uses a keyring to check the package.



OpenBSD uses signify.



minisign looks interesting as you can add text to be displayed (like the Replicant version) in the signature.


Specific tool

The tool could use other schemes, like something similar to signify or a keyring.


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.


Schemes could also be combined.

So far we have the following install flow: Recovery signature -> Recovery -> zip

The users check the recovery signature, and the recovery then check the zip.

The recovery could be signed with a Replicant contributor key, while it could check the signatures of the zip through a keyring for instance.