GrapheneOS-Knowledge

This is a short description of some of the knowledge I've collected on GrapheneOS and some common questions I've been asked and my answers to them.

Explore on GitHub Read Hacker News discussions

3Distinct people

4Mentions

0Explicit recommenders

92GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

This is a short description of some of the knowledge I've collected on GrapheneOS and some common questions I've been asked and my answers to them.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month4 dated mentions

Observed mentions: 2020-11-03 22:07:06 UTC to 2021-09-02 13:39:20 UTC.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
Nov 2020	2020-11-01 00:00:00 UTC	2020-12-01 00:00:00 UTC	1	1
Dec 2020	2020-12-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	0	0
Jan 2021	2021-01-01 00:00:00 UTC	2021-02-01 00:00:00 UTC	0	0
Feb 2021	2021-02-01 00:00:00 UTC	2021-03-01 00:00:00 UTC	0	0
Mar 2021	2021-03-01 00:00:00 UTC	2021-04-01 00:00:00 UTC	0	0
Apr 2021	2021-04-01 00:00:00 UTC	2021-05-01 00:00:00 UTC	1	1
May 2021	2021-05-01 00:00:00 UTC	2021-06-01 00:00:00 UTC	0	0
Jun 2021	2021-06-01 00:00:00 UTC	2021-07-01 00:00:00 UTC	0	0
Jul 2021	2021-07-01 00:00:00 UTC	2021-08-01 00:00:00 UTC	0	0
Aug 2021	2021-08-01 00:00:00 UTC	2021-09-01 00:00:00 UTC	0	0
Sep 2021	2021-09-01 00:00:00 UTC	2021-10-01 00:00:00 UTC	2	2

What Hacker News says

4 sources

lucideer·Sep 2, 2021

This is just one example (linked below) but I've seen a fair bit of this type of behaviour just specifixally from the project founder/leader. There does seem to be a lot of other more level-headed folk involved with the project too however so not sure how insurmountable the problem is. https://github.com/Peter-Easton/GrapheneOS-Knowledge/issues/...

In NitroPhone – Pixel 4a phone with GrapheneOS

lucideer·Sep 2, 2021

I haven't found any yet, but it's likely out there given how heavily & directly the open-source GrapheneOS project relies on it. It's notable that GrapheneOS only currently supports the Google Pixel 4 and 5. e.g. Peter Easton wrote a short piece here https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/ma...

In NitroPhone – Pixel 4a phone with GrapheneOS

atat7024·Apr 12, 2021

The Librem 5 is not as open or libre as its marketing has tried to insinuate, simply having its binary blob signed and validated firmware saved in write-protected read-only memory and loaded by a secondary coprocessor to exploit a loophole in the definiton of "libre" hardware to allow it to qualify for the FSF's definiton of "Free" hardware. This renders the firmware unupdateable without shorting a connection. In the event a vulnerability is discovered in the modems or radios, the firmware cannot be updated without physically dismantling the phone. Firmware initialization is also no longer under the control of the host operating system because the initialization is carried out from outside the OS: changing or updating software on the host will not address these design defects. Although the modems and radios are not attached to the host vi

Read the rest

a DMA, they rely on USB for isolation, which simply shifts the trust from the kernel driver to the kernel USB stack, and USB was never designed with distrusting the device plugged into it in mind unlike SMMU/IOMMU, which is specifically designed to mitigate unconstrained DMA. Current releases of the Librem 5 have been plagued by thermal throttling issues and poor battery life which in some cases has clocked in at less than 1 hour at idle. The Librem 5 does not even support software encryption and no progress has been made toward adding even LUKS encryption. The Librem 5 lacks a secure element for any hardware binding on the encryption and so would be entirely dependent on software-only encryption. The rebranded version of Debian that the Librem 5 uses as an operating system uses the same security model as the desktop stack, which is a perimeter or "all or nothing" security model. In the future, applications may be installed utilizing FlatPak. The threat model and measures FlatPak takes to meet it are as of yet unclear and uncertain. From https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/ma... which may be mildly out of date — but I doubt it. tl;dr Wake me up when you have an IOMMU!

In Making Librem 5 Apps [video]

randomhydrosol·Nov 3, 2020

Copperhead is just selling a reskinned version of the open source project. They are also not secure as you can see from their website. There is no android 11 release and it's at least 3 months behind in security patches. That is not secure. If you check grapheneos it is using the most recent security patch and android version available Grapheneos has been around far longer than the commercial project. The commercial project was set up to fund the open source project however James Donaldson, the current copperhead CEO has a criminal background and tried to turn it into something completely different I encourage you to read https://github.com/Peter-Easton/GrapheneOS-Knowledge/blob/ma... to understand what really happened

In Secure Phone Series: Device Security