Its definitely being discussed and voting is happening as we speak.

So like I said, its definitely being discussed, you fuckin knob. That verbage is DIRECTLY FROM PROPOSAL “A” which means it has been discussed enough to include that in the text.

Learn to admit you were fucking wrong, idiot. You’re literally unnecessary in this thead, so far.

Literally in proposal A:

We will not allow direct contributions to Debian written with the use or assistance of large language models (LLMs) or other generative AI tools. Direct contributions are defined as packaging, native Debian software like lintian, documentation and translations written by Debian contributors, and official Debian web resources, etc. Other categories such as upstream projects written with LLM assistance may be included at a later date. This ensures that Debian remains a stable, trusted, and reliable operating system, and protects the interests of the Debian volunteers who make it possible.

Cool downvote tho

Its definitely being discussed and voting is happening as we speak.

https://www.debian.org/vote/2026/vote_002

They’re definitely going to be building it from source and delivering those packages though.

Im also certain they’re not going it catch it all in their own packages.

AI powered by the Arch Wiki and AUR

Regardless, they have no control over upstream packages. Are they going to move away from the linux kernel 100%?

Your TPM concern here…

If I get to add new hardware to phones, TPM would be on my list but not at the top. First might be something like POCSAG (plus build out the pager network again) so you can receive text messages without transmitting anything or revealing your location. Second, third, etc. would be in a similar vein.

…is literally addressed in your post here:

This is a start: https://grapheneos.social/@GrapheneOS/117140352254892456

They mention all the secure enclave type of stuff needed. They have the verified boot. They have the MTP. Its all there.

As for Pixels, this is in Dutch but very recent: https://www.omroepbrabant.nl/nieuws/6023856/drievoudige-moord-in-oosterhout-telefoon-van-verdachte-gekraakt

Were they using GrapheneOS?

Also, keep in mind that Cellebrite slides were leaked and they show that they arent able to tap into GrapheneOS on modern Pixel devices.

https://www.androidauthority.com/cellebrite-leak-google-pixel-grapheneos-security-platform

Until GrapheneOS breaks away from AOSP, which they have mentioned they could potentially do so once they have a solid hardware platform, we seem to at least be in a good place where even the DoJ is upset about people using GrapheneOS.

https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

That’s all very nice but not many of us are willing to buy a $1000 phone (or an obsolete Pixel) to get Graphene.

Pixel “a” series phones typically sell for under $500 and support GrapheneOS.

They soon won’t be able to run it on new Pixels, and also the stuff about AOSP updates stops mattering since AOSP itself is nearly dead.

Source for this?

The obsession with security chips (fighting the seized phone attack while comparatively ignoring much more relevant threats) is another misplaced priority. It’s the old notion of “fence post security”, putting a 100 foot fence post in the middle of the desert expecting the attacker to try to climb over it instead of going around it.1

The obsession with security chips is what allows Pixels and iPhones to be the most secure devices on the planet. They have some of the most researched technologies being used here. You’re literally just throwing it away based on…your link to a harry potter book? Seriously, look at the source you just shared. Its not even relevant 😂

And again, I’m amused at the idea of the US and Chinese governments allowing a Motorola (Lenovo) Graphene to be sold if it’s really that secure.

What are they going to do, ban security chips like they tried to ban encryption in the 90s?

We need a de-googled Android fork (maybe Lineage is that) on mass market phones using the hardware that those phones have. Otherwise we’re acquiescing to the notion that Elon Musk deserves more privacy than Joe Schmoe when it should be the other way around.

GrapheneOS and LineageOS are already degoogled… LineageOS is extremely subpar when it comes to security since they dont enforce it onto their hardware. GrapheneOS actually enforces it and wont work unless it has those specific security features. LineageOS doesnt solve the problem you were concerned about in your post.

Ask GrapheneOS. Thats literally their mission.

Device support

Devices are carefully chosen based on their merits rather than the project aiming to have broad device support. Broad device support is counter to the aims of the project, and the project will eventually be engaging in hardware and firmware level improvements rather than only offering suggestions and bug reports upstream for those areas. Much of the work on the project involves changes that are specific to different devices, and officially supported devices are the ones targeted by most of this ongoing work.

Hardware, firmware and software specific to devices like drivers play a huge role in the overall security of a device. The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware.

Non-exhaustive list of requirements for future devices, which are standards met or exceeded by current Pixel devices:

• Support for using alternate operating systems including full hardware security functionality
• Complete monthly Android Security Bulletin patches without any regular delays longer than a week for device support code (firmware, drivers and HALs)
• At least 5 years of updates from launch for device support code with phones (Pixels now have 7) and 7 years with tablets
• Device support code updated to new monthly, quarterly and yearly releases of AOSP within several months to provide new security improvements (Pixels receive these in the month they’re released)
• Linux 6.1, 6.6 or 6.12 Generic Kernel Image (GKI) support
• Hardware accelerated virtualization usable by GrapheneOS (ideally pKVM to match Pixels but another usable implementation may be acceptable)
• Hardware memory tagging (ARM MTE or equivalent)
• Hardware-based coarse grained Control Flow Integrity (CFI) for baseline coverage where type-based CFI isn’t used or can’t be deployed (BTI/PAC, CET IBT or equivalent)
• PXN, SMEP or equivalent
• PAN, SMAP or equivalent
• Isolated radios (cellular, Wi-Fi, Bluetooth, NFC, etc.), GPU, SSD, media encode and decode, image processor and other components
• Support for A/B updates of both the firmware and OS images with automatic rollback if the initial boot fails one or more times
• Verified boot with rollback protection for firmware
• Verified boot with rollback protection for the OS (Android Verified Boot)
• Verified boot key fingerprint for yellow boot state displayed with a secure hash (non-truncated SHA-256 or better)
• StrongBox keystore provided by secure element
• Hardware key attestation support for the StrongBox keystore
• Attest key support for hardware key attestation to provide pinning support
• Weaver disk encryption key derivation throttling provided by secure element
• Insider attack resistance for updates to the secure element (Owner user authentication required before updates are accepted)
• Inline disk encryption acceleration with wrapped key support
• 64-bit-only device support code
• Wi-Fi anonymity support including MAC address randomization, probe sequence number randomization and no other leaked identifiers
• Support for disabling USB data and also USB as a whole at a hardware level in the USB controller
• Reset attack mitigation for firmware-based boot modes such as fastboot mode zeroing memory left over from the OS and delaying opening up attack surface such as USB functionality until that’s completed
• Debugging features such as JTAG or serial debugging must be inaccessible while the device is locked

In order to support a device, the appropriate resources also need to be available and dedicated towards it. Releases for each supported device need to be robust and stable, with all standard functionality working properly and testing for each of the releases.

The expectation is for people to buy a secure device meeting our requirements to run GrapheneOS. Broad device support would imply mainly supporting very badly secured devices unable to support our features. It would also take a substantial amount of resources away from our work on privacy and security, especially since a lot of it is closely tied to the hardware such as the USB-C port control and fixing or working around memory corruption bugs uncovered by our features. We plan to partner with OEMs to have devices produced meeting all our requirements, providing additional privacy/security features beyond them and ideally shipping with GrapheneOS rather than massively lowering our standards.

You believe GrapheneOS is not able protect against Motorola? Or do you think GrapheneOS is weaking the OS specifically for Motorola? Do you believe that’s also the case for Google with their Pixels and the USgovt? Are you saying stay on stock Android? Is there another mobile OS you are recommending? Your message is not clear and you seem to be making unsubstantiated claims with no evidence to back it up.

Damn the CCP for building secure hardware!

This thumbnail was very odd until I looked at the full sized photo

This will probably be the actual name tbh

EdgeOS!

Also, itll still prompt you to make EdgeOS your default OS

They gotta be trolling the entire linux userbase at this point.

Those devices should most certainly be on two separate networks. Internet facing devices should be on a DMZ and not be allowed to talk to your internal network. You can then allow your internal network reach your DMZ devices, but only allow return traffic from the DMZ.