GrapheneOSMar 6

The official microG OS project (https://lineage.microg.org/) leaked their private keys for logging into their servers and signing releases:

https://github.com/lineageos4microg/l4m-wiki/wiki/December-2025-security-issues

We make our official builds on local machines. Our signing machine's keys aren't ever on any storage unencrypted.

LineageOS for microG

LineageOS for microG website.

LineageOS for microG
Show threadGrapheneOSMar 6
Our roadmap for improving security of verifying updates is based on taking advantage of the reproducible builds. We plan to have multiple official build locations and a configurable signoff verification system in the update clients also usable with third party signoff providers.
Show threadGrapheneOSMar 6
We don't have faith in any available commercial HSM products being more secure than keeping keys encrypted at rest on the primary local build machine. Instead, we're planning to develop software for using the secure element on GrapheneOS phones as an HSM for signing our releases.
Show threadzSchön 
@GrapheneOS Shouldn’t signing be separate from the build machine since compilation brings its own attack vectors? (Although the transmission would also add different attack vectors)
Mar 6 at 6:21pmWeb
Show threadGrapheneOSMar 6

@TheAlgorythm No, since Android's signing system trusts the output of the build so the only way to secure them more is running them in a container or VM with restricted access.

Android Open Source Project has an upstream container system for the build process although the intended purpose is not security. The purpose of their build sandbox is avoiding build determinism issues and also avoiding accidental damage being done to the host system or account.

Show threadzSchön Mar 6
@GrapheneOS Well yes. But it was not about the trust on the binary produced by the compiler. There is not much you can do to increase it. It was about (malicious) side effects the compilation process could have on the build system. Although the likelihood should be low.