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 threadcedric_cvlMar 6
@GrapheneOS what do you use to encrypt keys at rest and make them available when needed?
Show threadGrapheneOS
@cedric_cvl Standard OpenSSL scrypt + AES key encryption with a noswap configured tmpfs for using the decrypted keys where they're wiped after usage. It's not anything complex. It avoids the unencrypted keys ever being on storage so they're at rest whenever builds aren't being signed. Otherwise, they wouldn't be at rest much since these machines are rarely turned off and disk encryption wouldn't be enough of a protection alone especially with desktops not being as secure as the phones at all.
Mar 6 at 6:04pmWeb