postmarketOS will never ask for your ID to let users install your app!

@postmarketOS context please?

@postmarketOS postmarketOS should never prevent you from running whatever software you please

imho this is another point in favour of having the end users as the root of trust: our job is to build software for the masses without relying on centralised trust and that means if/when we ever offer an API for apps to establish trust with the system it should effectively boil down to user confirmation that the system can be trusted

how does the user know that? well that's the fun part where the security folks can go wild :D

(i would assume comparing key fingerprints and trusting measured boot)

@omasanori @postmarketOS https://arstechnica.com/gadgets/2025/08/google-will-block-sideloading-of-unverified-android-apps-starting-next-year/

@clot27 @postmarketOS thanks

@postmarketOS, there is a certain UK politician that will probably yell at you soon because of this :p

@postmarketOS I donated to the right project

@omasanori @postmarketOS https://www.androidauthority.com/android-developer-verification-requirements-3590911/

@beowulf thanks

@omasanori @postmarketOS

https://www.androidsage.com/2025/08/26/google-blocks-sideloading-of-android-apps/

@omasanori @postmarketOS probably related to https://9to5google.com/2025/08/25/android-apps-developer-verification/

@unfinishedsymphony thanks

@omasanori Likely this https://arstechnica.com/gadgets/2025/08/google-will-block-sideloading-of-unverified-android-apps-starting-next-year/ @postmarketOS

@cyp thanks

@linmob thanks

@cas @postmarketOS The only possible measure of trust is whether the device is the same physical one we expect it to be and whether it has been tampered with since we set it up/last used it.

None of the surveillance-masquerading-as-security-theater even addresses this. It's all evaluating whether a "platform owner" has the backdoor they expect.

You need actual hardware mechanics designed around detecting tampering (intrinsically visible to the user, not trusting that software detects & reports it, which is useless because it's spoofable) to get any kind of safety here.

@dalias @postmarketOS like a TPM that controls an LED? i'm led to believe there are ways to somehow present this through software without trusting it inherently but it's all a bit beyond me tbh

@postmarketOS i use ubuntu on phone, similarly good with installations. literally just
git clone; cd; make; make install
and some command to run later (if needs) ;p

@postmarketOS or from pip, yet quicker…

@omasanori @postmarketOS Google is in the process of locking down all installations of Android that include Google Play Services, so you need to verify your ID with Google to have your apps be allowed to be installed

@cas @postmarketOS There isn't. The tampering party could have cut or rewired the LED.

@cas @postmarketOS Their entire threat model assumes the attacker is the user or indirectly software the user allowed to run on the device as root. It does not address the real threat of hardware tampering or swapping at all.

@postmarketOS can you guys do a blog post about what steps need to be done to get it to run on one recent phone. E.g. OnePlus 13 or 13R given that OnePlus still let's us unlock bootloader...

Then estimate it in terms of people needed to realize this in one year.

Then we can convert it to money.

Then maybe this would be a motivation to get crowdfunded.

@navi thanks

@postmarketOS I have been following this for a while now and while progress is there, there is still nothing usable.

How do we get from where we are now to one phone which works?

And I mean one phone that is from 2020s...

@cas @postmarketOS Tampering can be detected with platform hardware by storing key material in volatile memory that's destroyed and has to be recovered by re-entry if the device is opened or enclosure integrity is compromised. Device identity (think: border crossing steals your real phone, replaces it with an identical one with modified pmOS installed with nothing but vnc proxy to your real phone to MITM your unlocking) is harder but solvable with the right hardware. But any "measuring boot" is useless without already having these two solved.

@dalias @cas @postmarketOS if you have disk encryption which gets autounlocked by TPM and someone tampers with it (such as switching to a different initrd or stuff) it’ll refuse to unlock and you’ll have to type the disk password. Having to type the password would be a pretty good alert that there’s something wrong with your device I think. That’s the way one of my NixOS devices is configured rn (eventually I’ll do it to my other ones too but I don’t really wanna backup my almost 4TB home folder rn lmao, I should probably do the laptop first then (tho autounlock is probably useless on that one)), not sure if phones have TPMs too.

@luana @dalias @cas @postmarketOS how do you configure it to do that?

@luana @cas @postmarketOS Yes, but that only addresses tampering via replacing the software. If someone has the physical means to do that, they have countless other more effective means of exfiltrating data or backdooring the system that doesn't require replacing the initrd or kernel and that wouldn't be visible through software.

@cas @tauon @postmarketOS @dalias

Like this: https://github.com/LuNeder/nixos-config/commit/d4b05b1059ad49ea4c3919ef0b0daab39280800c

This is for the boot drive, and then the HDDs have their zfs encryption keys saved on the rootfs of the LUKS encrypted and autounlocked boot SSD.

@tauon @postmarketOS @dalias @cas And then here’s the configuration for the ZFS HDDs with their keys on the rootfs (and sops)

https://github.com/LuNeder/nixos-config/commit/54e33b55c6c16d35c6d10856c565652893ae0bb0

https://github.com/LuNeder/nixos-config/commit/76a0cc95fd3ebfeaa26fe4c4521e0293df2d1ff6

@postmarketOS @dalias @cas Also I don’t think much change would be needed on lanzaboote in order to make it work with full-on systemd measured boot for PCR 11 (rn I measure PCRs 0+2+7+12+13+14+15 in order to unlock the disk, systemd measured boot measures PCR 11 in order to boot), since it already works by making an UKI image of your system anyway.

(Unrelated rant: For me this is proof that that stuff that GNOME does on GNOME OS is just complete bullshit. You don’t need a closed down system that doesn’t even let you change your DE in order to have measured boot. And even arch can do UKI automatically too these days without removing pacman.
And unrelated but for me NixOS itself also completely calls out the bullshit of “immutable systems” that don’t even let you change your DE (ie openSUSE Aeon) by giving you literally all advantages those have without the bullshit.
If you do it right and use a decent package manager you can do these stuff without making an open source iOS but worse.)

@cas @postmarketOS @dalias Such as what? Do note that as far as I’m aware this method is supposed to be safe against an evil maid attack.

I mean, if they put on a hardware that sits between the screen connector and the screen and is able to record everything then maybe but if you’re at that point you probably have bigger issues anyway. Proprietary phones wouldn’t protect you against this either, and having an hypothetical attack surface doesn’t mean you shouldn’t protect against the other possible attacks. Just know your own threat model.

@luana @cas @postmarketOS That's what I'm saying: it doesn't defend against evil maid attacks. It defends against one particular form of evil maid attack, modifying the software once you open up the device rather than just inserting a bug (in the old fashioned sense). But that's not actually what the people who make & push these systems are thinking about as their threat model.

Rather, their threat model is that malicious code is running in "ring 0" because your OS isn't trusted to be secure, while their "ring -1" OS under it somehow is trusted to be secure. And despite it already being game-over if your OS is compromised, they deem it a bigger game-over if the malicious code can achieve "persistence" modifying some layer below the OS.

@omasanori
I think this toot refers to Google announcement to "prevent" user from side loading software on their devices.
@postmarketOS

@dalias reminds me of knox…

@postmarketOS @dalias @cas No, this is NOT vulnerable to getting malicious code “below the OS”. PCR0 measures the UEFI, so a malicious bios is a nope. There are also PCRs measuring the bootloader and even your boot options (on grub command line for example). Sure, you also need to take the steps to make your OS secure agaist password resets (PCR8 and PCR12 do that I think), and trust that Linux itself is safe.

@luana @postmarketOS @cas Sorry I wasn't clear. I'm not saying it's vulnerable to malicious code below the OS. I'm saying the main threat model the people pushing this stuff care about is malicious code below the OS.

(Which wouldn't/couldn't be a thing if there weren't code below the OS to begin with.)

@Ariantoser thanks

@dalias @luana @postmarketOS tbh my primary threat model (and that of the vast majority of people in the world i would guess) is in priority order

a) disk corruption/bad update or something else making my device unusable and forcing me to reflash or otherwise need a second device in order to repair

b) opportunistic malware (not targeted at me)

c) spear phishing or other attacks targeted at me more specifically (needs a lot more than an immutable os and tpm to defend against)

d) evil maid attacks as you described earlier (getting into james bond territory here tho)

e) wrench attacks

in many countries (i think germany included) the state can force you to give up your encryption keys or face a fine/prison, so at this point i dont think the issue is really sensible to focus on

i just want a reliable and flexible device in my pocket that i can be confident has not been compromised in some way... Then maybe we look at doing virtual machines per app and other whacky stuff to preserve privacy

@cas @luana @postmarketOS I think to most of us (a) is still the biggest threat, and most of the lockdowns supposedly mitigating other threats make (a) vastly worse, such that you lose all your data on any kind of minor hardware or software fault.

This in turn necessitates letting the device vendor exfiltrate all your data to back it up for you. 🤬 🤮

It's particularly offensive that all of the commercial FDE models don't let you possess your own key to be able to recover data from the raw flash if the device fails in any way. Except for someone in (d)/(e) threat range, printing/writing down a key in physical form and storing it in a safe place is a perfectly reasonable thing to do.

@cas @luana @postmarketOS Speaking of that... maybe we should have a project to flesh out the usability parts of Bakelite and try to have it be a thing pmOS encourages using.

@dalias @luana @postmarketOS what that?

@cas @luana @postmarketOS https://github.com/richfelker/bakelite

@dalias @luana oh i see

would be cool if you made some comparisons to other solutions, i've been using borgbase for a while now with pika backup (which i think works on mobile, it's libadwaita at least)

@postmarketOS @cas @dalias

This in turn necessitates letting the device vendor exfiltrate all your data to back it up for you. 🤬 🤮

Uhhhh what? You can just backup your stuff wherever you want lol?

@luana @postmarketOS @cas I'm talking about how it's done in practice on Apple and Google operating systems, not how it could/should be done. See the paragraph below ("commercial FDE models"). Sorry I didn't state that very clearly.

@postmarketOS I love a freedom way by doing anything we want.

@cas @luana It's been a while since I delved into all the options out there, but generally where the otherwise-good ones all fail is either having key material that can decrypt the backups on the machine being backed up (this lets a 32-byte exfiltration turn into compromise of all past and current/future backups stored anywhere attacker can get to them) or not being sufficiently "incremental" to avoid massive space and bandwidth requirements.