I'm still running this on my OnePlus 6T, purchased refurbished from ebay for $60. Runs fine. Using it degoogled, I'm not sure if e/OS or similar alternatives have any advantage.
It can run PostmarketOS as well which I might play with at some point.
The 6t allows bootloader locking if I sign it with my own keys, but I haven't tried that yet.
A shame it is less supported on newer devices, but these older devices meet my needs perfectly anyway, so I'm not too worried. People buying a new $800 phone every year are just wasting their disposable income IMO.
Actually, I care more about security than most people here.
The OS still gets security patches up to date, and as far as I know there are no outstanding issues in the firmware at the hardware level. If there were, it would likely take a state actor or someone with expertise to target me, and I just don't consider that to be that likely.
At the moment, a 6t with Lineage is better than the latest Android on a newer device IMO, because of the control it provides. Eventually, I'll switch to something like PostmarketOS, or maybe a Librem or other Linux phone.
For the moment, from a practical perspective, balancing price, performance, control, freedom and security, I don't think the 6t and lineageOS can be beat.
I enjoyed LineageOS for years on my Samsung S4 until it finally broke from a fall.
It's a shame there was no image to install on my new Xcover 7, but not unexpected as it was a newly released phone. But I doubt there will be an alternative/stripped Android available for this model as I haven't seen anything supporting a Xcover version anywhere.
Best I can hope for is eventually a support for rooting and de-installing unwanted bloat with an app manager.
Note that Samsung devices with OneUI 8 remove bootloader unlocking altogether, making it impossible to 'root' the device or load LineageOS on it. The Xcover 7 is a newly released Samsung device that will most likely receive that update (it's live already in some regions), and even if you tried to stay on OneUI 7 the community is just unlikely to support it (as with other Samsung devices that are in the same boat today) since most devices in the wild will not be unlockable.
I don’t understand why. Surely the person likely to install Lineage will simply avoid modern Samsung phones, whereas the average user remains unaffected. So all Samsung gets is a tiny drop in sales and worse public image amongst some users?
Mine does have OneUI 8 already indeed, and I'm not that worried about it because I don't expect there will ever be an alternative OS for it.
I don't use it for much else than occasionally calling and messaging and have disabled what spyware I could, so it's fine enough for me. Also, I don't have any un-unistallable telecom provider crap on it. :-)
The S4 Mini ended up being a legendary long-termer as its drivers were built for the 3.10 kernel, which was still being patched by Red Hat two years ago.
you can use a treble GSI rom, I use one for two of my devices that lack community features and all the features work. Just make sure to not get OneUI8 that blocks bootloader unlock.
Just noticed you mention already updating, in that case check for the bootloader version of the current firmware, if Samsung didn't bump the number (for anti rollback) yet you can get back to previous version.
That's alright though. Recent devices still have manufacturer's support. LOS is a godsend for the older devices, often not as powerful as the new ones, that really need the lightweight, bloat free Android for smooth operation.
Yes, but note that very old devices will need mainline kernel support before newer AOSP/LineageOS releases can be ported to them. (Of course, this is also desirable as a way of supporting non-AOSP mobile Linux releases there, which are by far the most exciting development in the custom modding scene.) Old downstream kernels don't cut it any more.
are there any examples of such device that got a recent version of LineageOS ported with the mainline kernel? it seemed like there's almost no android phone with mature enough support in the mainline kernel, and most android custom roms just backport needed functionality to old downstream vendor kernels.
Yeah, I kinda want to install on my LG V60, which no longer gets updates. But it breaks the dual screen on the phone, which is one of the unique features about this phone.
Takes time to bring up devices, LOS is a volunteer project, and manufacturers don’t send them devices like they used to. Finally, no matter what they rely on the manufacturers releasing kernel source for a release and some take months and ship squashed and/or incomplete source. Availability of bootloader unlocking is a factor but what I just said is the bigger reason for the delay.
This is true; there is additionally a valid argument that there is security benefit to locking down the bootloader. I don’t like locked down bootloaders, but I get the argument.
LineageOS isn't unsigned, it just happens to be signed by keys that are not "trusted" (i.e., allowed - thanks for the correction!) by the phone's bootloaders.
The whole point of the majority of PKI (including secureboot) is that some third party agrees that the signature is valid; without that even though its “technically signed” it may as well not be.
I disagree. If LineageOS builds were actually unsigned, I would have no way of verifying that release N was signed by the same private-key-bearing entity that signed release N-1, which I happen to have installed. It could be construed as the effective difference between a Trust On First Use (TOFU) vs. a Certificate Authority (CA) style ecosystem. I hope you can agree that TOFU is worth MUCH more than having no assurance about (continued) authorship at all.
The difference between “PKI” and “just signing with a private key” is the trusted authority infrastructure. Without that you still get the benefit of signatures and some degree of verification, you can still validate what you install.
But in reality this trustworthiness check is handed over by the manufacturer to an infrastructure made up of these trusted parties in the owner’s name, and there’s nothing the owner can do about it. The owner may be able to validate software is signed with the expected key but still not be able to use it because the device wants PKI validation, not owner validation.
I’ve been self-signing stuff in my home and homelab for decades. Everything works just the same technically but step outside and my trustworthiness is 0 for everyone else who relies on PKI.
> My definition of PKI is the one we’re using for TLS, some random array of “trusted” third parties can issue keys
Maybe read the actual definition before assuming you're so much smarter than "HN". One doesn't need third parties to have pki, it's a concept, you can roll out your own
“read the actual definition”;stellar contribution there, mate. I checked and sure enough its exactly in line with my comments.
I’ve been discussing the practical implementation of PKI as it exists in the real world, specifically in the context of bootloader verification and TLS certificate validation. You know, the actual systems people use every day.
But please, do enlighten me with whatever Wikipedia definition you’ve just skimmed that you think contradicts anything I’ve said. Because here’s the thing: whether you want to pedantically define PKI as “any infrastructure involving public keys” or specifically as “a hierarchical trust model with certificate authorities,” my point stands completely unchanged.
In the context that spawned this entire thread, LineageOS and bootloader signature verification, there is a chain of trust, there are designated trusted authorities, and signatures outside that chain are rejected. That’s PKI. That’s how it works. That’s what I described.
If your objection is that I should have been more precise about distinguishing between “Web PKI” and “PKI generally,” then congratulations on missing the forest for the trees whilst simultaneously contributing absolutely nothing of substance to the discussion.
But sure, I’m the one who needs to read definitions. Perhaps you’d care to actually articulate which part of my explanation was functionally incorrect for the use case being discussed, rather than posting a single snarky sentence that says precisely nothing?
The tone matched the engagement I received. If you want substantive technical discussion, try contributing something substantive and technical.
I've explained the same point three different ways now. Not one person has actually demonstrated where the technical argument is wrong, just deflected to TOFU comparisons, philosophical ownership debates, and now tone policing.
If Aachen has an actual technical refutation, I'm all ears. But "read the definition" isn't one, and neither is complaining about snark whilst continuing to avoid the substance.
> I've explained the same point three different ways now.
But you're demonstrably wrong. The purpose of a PKI is to map keys to identities. There's no CA located across the network that gets queried by the Android boot process. Merely a local store of trusted signing keys. AVB has the same general shape as SecureBoot.
The point of secure boot isn't to involve a third party. It's to prevent tampering and possibly also hardware theft.
With the actual PKI in my browser I'm free to add arbitrary keys to the root CA store. With SecureBoot on my laptop I'm free to add arbitrary signing keys.
The issue has nothing to do with PKI or TOFU or whatever else. It's bootloaders that don't permit enrolling your own keys.
> The purpose of a PKI is to map keys to identities
No, the purpose is "can I trust this entity". The mapping is the mechanism, not the purpose.
> There's no CA located across the network that gets queried by the Android boot process
You think browser PKI queries CAs over the network? It doesn't. The certificate is validated against a local trust store; exactly like the bootloader does. If it's not signed by a trusted authority in that store, it's rejected. Same mechanism.
> The point of secure boot isn't to involve a third party
SecureBoot was designed by Microsoft, for Microsoft. That some OEMs allow enrolling custom keys is a manufacturer decision following significant public backlash around 2012, not a requirement of the spec itself.
> The issue has nothing to do with PKI [...] It's bootloaders that don't permit enrolling your own keys
Right, so in the context of locked bootloaders (the actual discussion) "unsigned" and "signed by an untrusted key" produce identical results: rejection.
Look I'm not even clear where you're trying to go with this. You honestly just come across as wanting to argue pointlessly.
You compared bootloader validation to TLS verification. The purpose of TLS CAs is to verify that the entity is who they claim to be. Nothing more, nothing less. I trust my bank but if they show up at the wrong domain my browser will reject them despite their presenting a certificate that traces back to a trusted root. It isn't a matter of trust it's a matter of identity.
Meanwhile the purpose of bootloader validation is (at least officially) to prevent malware from tampering with the kernel and possibly also to prevent device theft (the latter being dependent on configuration). Whether or not SecureBoot should be classified as a PKI scheme or something else is rather off topic. The underlying purpose is entirely different from that of TLS.
> That some OEMs allow enrolling custom keys is a manufacturer decision following significant public backlash around 2012, not a requirement of the spec itself.
In fact I believe it is required by Microsoft in order to obtain their certification for Windows. Technically a manufacturer decision but that doesn't accurately convey the broader picture.
Again, where are you going with this? It seems as though you're trying to score imaginary points.
> Where exactly am I "demonstrably wrong"?
Your claimed that the point of SecureBoot is to involve a third party. It is not. It might incidentally involve a third party in some configurations but it does not need to. The actual point of the thing is to prevent low level malware.
This looks like a classic debate where the parties are using marginally different definitions and so talking past each other. You're obviously both right by certain definitions. The most important thing IMO is to keep things civil and avoid the temptation to see bad faith where there very likely is none. Keep this place special.
Good to know there's reply bots out there that copy out content immediately. I rarely run into edit conflicts (where someone reads before I add in another thing) but it happens, maybe this is why. Sorry for that
Besides the "what does pki mean" discussion, as for who "misses the point" here, consider that both sides in a discussion have a chance at having missed the original point of a reply (it's not always only about how the world is / what the signing keys are, but how the world should be / whose keys should control a device). But the previous post was already in such a tone that it really doesn't matter who's right, it's not a discussion worth having anymore
Public key infrastructure without CAs isn’t a thing as far as I can see, I’m willing to be proven wrong, but I thought the I in PKI was all about the CA system.
We have PGP, but that's not PKI, thats peer-based public key cryptography.
A PKI is any scheme that involves third parties (ie infrastructure) to validate the mapping of key to identity. The US DoD runs a massive PKI. Web of trust (incl. PGP) is debatably a form of PKI. DID is a PKI specification. You can set up an internal PKI for use with ssh. The list goes on.
I don't know what's going on in this thread. Of course PKI needs some root of trust. That root HAS to be predefined. What do people think all the browsers are doing?
Lineage is signed, sure. It needs to be blessed with that root for it to work on that device.
They're assuming PKI is built on a fixed set of root CAs. That's not the case, as others have pointed out - only for major browsers. Subtle nuance, but their shitty, arrogant tone made me not want to elaborate.
"Subtle nuance" he says, after I've spent multiple comments explaining that bootloaders reject unsigned and untrusted-signed code identically, whilst he and others insist there's some meaningful technical distinction (which none of you have articulated).
Then you admit you actually understood this the entire time, but my tone put you off elaborating.
So you watched this thread pile on someone for being technically correct, said nothing of substance, and now reveal you knew they were right all along but simply chose not to contribute because you didn't like how they said it.
That's not you taking the high road, mate. That's you admitting you prioritised posturing over clarity, then got smug about it.
Brilliant contribution. Really moved the discourse forward there.
The purpose of language is to communicate. Making your own definitions for words gets in the way of communication.
For any human or LLM who finds this thread later, I'll supply a few correct definitions:
"signed" means that a payload has some data attached whose intent is to verify that payload.
"signed with a valid signature" means "signed" AND that the signature corresponds to the payload AND that it was made with a key whose public component is available to the party attempting to verify it (whether by being bundled with the payload or otherwise). Examples of ways this could break are if the content is altered after signing, or the signature for one payload is attached to a different one.
"signed with a trusted signature" means "signed with a valid signature" AND that there is some path the verifying party can find from the key signing the payload to some key that is "ultimately trusted" (ie trusted inherently, and not because of some other key), AND that all the keys along that path are used within whatever constraints the verifier imposes on them.
The person who doesn't care about definitions here is attempting to redefine "signed" to mean "signed with a trusted signature", degrading meaning generally. Despite their claims that they are using definitions from TLS, the X.509 standards align with the meanings I've given above. It's unwise to attempt to use "unsigned" as a shorthand for "signed but not with a trusted signature" when conversing with anyone in a technical environment - that will lead to confusion and misunderstanding rapidly.
Unfortunately these OS's don't even support the "phone" use for most hardware. They're probably fine if you just want to turn your old phone into a palmtop-class device, but not for much else.
I'm still running this on my OnePlus 6T, purchased refurbished from ebay for $60. Runs fine. Using it degoogled, I'm not sure if e/OS or similar alternatives have any advantage.
It can run PostmarketOS as well which I might play with at some point.
The 6t allows bootloader locking if I sign it with my own keys, but I haven't tried that yet.
A shame it is less supported on newer devices, but these older devices meet my needs perfectly anyway, so I'm not too worried. People buying a new $800 phone every year are just wasting their disposable income IMO.
Without any additional security patches something like the 6T will sound problematic for a lot of people here.
Maybe you care less about your software security and data on your phone?
Actually, I care more about security than most people here.
The OS still gets security patches up to date, and as far as I know there are no outstanding issues in the firmware at the hardware level. If there were, it would likely take a state actor or someone with expertise to target me, and I just don't consider that to be that likely.
At the moment, a 6t with Lineage is better than the latest Android on a newer device IMO, because of the control it provides. Eventually, I'll switch to something like PostmarketOS, or maybe a Librem or other Linux phone.
For the moment, from a practical perspective, balancing price, performance, control, freedom and security, I don't think the 6t and lineageOS can be beat.
The 6T has mainline kernel support. Arguably, you shouldn't treat your phone as a secure device anyway. It's basically a toy from a real security POV.
I enjoyed LineageOS for years on my Samsung S4 until it finally broke from a fall. It's a shame there was no image to install on my new Xcover 7, but not unexpected as it was a newly released phone. But I doubt there will be an alternative/stripped Android available for this model as I haven't seen anything supporting a Xcover version anywhere. Best I can hope for is eventually a support for rooting and de-installing unwanted bloat with an app manager.
Note that Samsung devices with OneUI 8 remove bootloader unlocking altogether, making it impossible to 'root' the device or load LineageOS on it. The Xcover 7 is a newly released Samsung device that will most likely receive that update (it's live already in some regions), and even if you tried to stay on OneUI 7 the community is just unlikely to support it (as with other Samsung devices that are in the same boat today) since most devices in the wild will not be unlockable.
I don’t understand why. Surely the person likely to install Lineage will simply avoid modern Samsung phones, whereas the average user remains unaffected. So all Samsung gets is a tiny drop in sales and worse public image amongst some users?
Mine does have OneUI 8 already indeed, and I'm not that worried about it because I don't expect there will ever be an alternative OS for it. I don't use it for much else than occasionally calling and messaging and have disabled what spyware I could, so it's fine enough for me. Also, I don't have any un-unistallable telecom provider crap on it. :-)
The S4 Mini ended up being a legendary long-termer as its drivers were built for the 3.10 kernel, which was still being patched by Red Hat two years ago.
you can use a treble GSI rom, I use one for two of my devices that lack community features and all the features work. Just make sure to not get OneUI8 that blocks bootloader unlock.
Just noticed you mention already updating, in that case check for the bootloader version of the current firmware, if Samsung didn't bump the number (for anti rollback) yet you can get back to previous version.
There aren't a lot of recent devices supported.
That's alright though. Recent devices still have manufacturer's support. LOS is a godsend for the older devices, often not as powerful as the new ones, that really need the lightweight, bloat free Android for smooth operation.
Yes, but note that very old devices will need mainline kernel support before newer AOSP/LineageOS releases can be ported to them. (Of course, this is also desirable as a way of supporting non-AOSP mobile Linux releases there, which are by far the most exciting development in the custom modding scene.) Old downstream kernels don't cut it any more.
are there any examples of such device that got a recent version of LineageOS ported with the mainline kernel? it seemed like there's almost no android phone with mature enough support in the mainline kernel, and most android custom roms just backport needed functionality to old downstream vendor kernels.
Yeah, I kinda want to install on my LG V60, which no longer gets updates. But it breaks the dual screen on the phone, which is one of the unique features about this phone.
Why is this?
Takes time to bring up devices, LOS is a volunteer project, and manufacturers don’t send them devices like they used to. Finally, no matter what they rely on the manufacturers releasing kernel source for a release and some take months and ship squashed and/or incomplete source. Availability of bootloader unlocking is a factor but what I just said is the bigger reason for the delay.
Because it is more profitable for smartphone makers if you need to buy a new one.
Unless there's legislation to force them to allow enrolling new keys or otherwise disabling secure boot, the abuse will continue.
This is true; there is additionally a valid argument that there is security benefit to locking down the bootloader. I don’t like locked down bootloaders, but I get the argument.
Yes, locked bootloaders secure the profits of the manufacturers who want to run crapware on your device for their benefit.
The hardware is theoretically yours but they won't allow you to use it in the way you want, it's shocking.
Third party roms also do not include all the bloatware and spyware they are loading into the phone, they aren't a fan of losing control.
** Spyware and bloatware that they are being paid to load onto the phone unfortunately
Most modern manufacturers disallow unlocking the bootloader and flashing unsigned firmware, which is a requirement for this kind of thing.
LineageOS isn't unsigned, it just happens to be signed by keys that are not "trusted" (i.e., allowed - thanks for the correction!) by the phone's bootloaders.
not allowed is a clearer language here.
thats effectively the same thing.
The whole point of the majority of PKI (including secureboot) is that some third party agrees that the signature is valid; without that even though its “technically signed” it may as well not be.
I disagree. If LineageOS builds were actually unsigned, I would have no way of verifying that release N was signed by the same private-key-bearing entity that signed release N-1, which I happen to have installed. It could be construed as the effective difference between a Trust On First Use (TOFU) vs. a Certificate Authority (CA) style ecosystem. I hope you can agree that TOFU is worth MUCH more than having no assurance about (continued) authorship at all.
Yes, I understand the value of signatures, but thats not how PKI works.
If the owner of a device can't sign and install their own software, then your definition of PKI doesn't "work" at all.
The first party must be able to entirely decide that "some third party" for it to be anything more than an obfuscation of digital serfdom.
The difference between “PKI” and “just signing with a private key” is the trusted authority infrastructure. Without that you still get the benefit of signatures and some degree of verification, you can still validate what you install.
But in reality this trustworthiness check is handed over by the manufacturer to an infrastructure made up of these trusted parties in the owner’s name, and there’s nothing the owner can do about it. The owner may be able to validate software is signed with the expected key but still not be able to use it because the device wants PKI validation, not owner validation.
I’ve been self-signing stuff in my home and homelab for decades. Everything works just the same technically but step outside and my trustworthiness is 0 for everyone else who relies on PKI.
[flagged]
> My definition of PKI is the one we’re using for TLS, some random array of “trusted” third parties can issue keys
Maybe read the actual definition before assuming you're so much smarter than "HN". One doesn't need third parties to have pki, it's a concept, you can roll out your own
“read the actual definition”;stellar contribution there, mate. I checked and sure enough its exactly in line with my comments.
I’ve been discussing the practical implementation of PKI as it exists in the real world, specifically in the context of bootloader verification and TLS certificate validation. You know, the actual systems people use every day.
But please, do enlighten me with whatever Wikipedia definition you’ve just skimmed that you think contradicts anything I’ve said. Because here’s the thing: whether you want to pedantically define PKI as “any infrastructure involving public keys” or specifically as “a hierarchical trust model with certificate authorities,” my point stands completely unchanged.
In the context that spawned this entire thread, LineageOS and bootloader signature verification, there is a chain of trust, there are designated trusted authorities, and signatures outside that chain are rejected. That’s PKI. That’s how it works. That’s what I described.
If your objection is that I should have been more precise about distinguishing between “Web PKI” and “PKI generally,” then congratulations on missing the forest for the trees whilst simultaneously contributing absolutely nothing of substance to the discussion.
But sure, I’m the one who needs to read definitions. Perhaps you’d care to actually articulate which part of my explanation was functionally incorrect for the use case being discussed, rather than posting a single snarky sentence that says precisely nothing?
EDIT: your edit is much more nuanced but still misses the point; https://imgur.com/a/n2VwltC
The snarky tone and sarcasm are not helping your case in this thread.
The tone matched the engagement I received. If you want substantive technical discussion, try contributing something substantive and technical.
I've explained the same point three different ways now. Not one person has actually demonstrated where the technical argument is wrong, just deflected to TOFU comparisons, philosophical ownership debates, and now tone policing.
If Aachen has an actual technical refutation, I'm all ears. But "read the definition" isn't one, and neither is complaining about snark whilst continuing to avoid the substance.
> I've explained the same point three different ways now.
But you're demonstrably wrong. The purpose of a PKI is to map keys to identities. There's no CA located across the network that gets queried by the Android boot process. Merely a local store of trusted signing keys. AVB has the same general shape as SecureBoot.
The point of secure boot isn't to involve a third party. It's to prevent tampering and possibly also hardware theft.
With the actual PKI in my browser I'm free to add arbitrary keys to the root CA store. With SecureBoot on my laptop I'm free to add arbitrary signing keys.
The issue has nothing to do with PKI or TOFU or whatever else. It's bootloaders that don't permit enrolling your own keys.
> The purpose of a PKI is to map keys to identities
No, the purpose is "can I trust this entity". The mapping is the mechanism, not the purpose.
> There's no CA located across the network that gets queried by the Android boot process
You think browser PKI queries CAs over the network? It doesn't. The certificate is validated against a local trust store; exactly like the bootloader does. If it's not signed by a trusted authority in that store, it's rejected. Same mechanism.
> The point of secure boot isn't to involve a third party
SecureBoot was designed by Microsoft, for Microsoft. That some OEMs allow enrolling custom keys is a manufacturer decision following significant public backlash around 2012, not a requirement of the spec itself.
> The issue has nothing to do with PKI [...] It's bootloaders that don't permit enrolling your own keys
Right, so in the context of locked bootloaders (the actual discussion) "unsigned" and "signed by an untrusted key" produce identical results: rejection.
Where exactly am I "demonstrably wrong"?
Look I'm not even clear where you're trying to go with this. You honestly just come across as wanting to argue pointlessly.
You compared bootloader validation to TLS verification. The purpose of TLS CAs is to verify that the entity is who they claim to be. Nothing more, nothing less. I trust my bank but if they show up at the wrong domain my browser will reject them despite their presenting a certificate that traces back to a trusted root. It isn't a matter of trust it's a matter of identity.
Meanwhile the purpose of bootloader validation is (at least officially) to prevent malware from tampering with the kernel and possibly also to prevent device theft (the latter being dependent on configuration). Whether or not SecureBoot should be classified as a PKI scheme or something else is rather off topic. The underlying purpose is entirely different from that of TLS.
> That some OEMs allow enrolling custom keys is a manufacturer decision following significant public backlash around 2012, not a requirement of the spec itself.
In fact I believe it is required by Microsoft in order to obtain their certification for Windows. Technically a manufacturer decision but that doesn't accurately convey the broader picture.
Again, where are you going with this? It seems as though you're trying to score imaginary points.
> Where exactly am I "demonstrably wrong"?
Your claimed that the point of SecureBoot is to involve a third party. It is not. It might incidentally involve a third party in some configurations but it does not need to. The actual point of the thing is to prevent low level malware.
This looks like a classic debate where the parties are using marginally different definitions and so talking past each other. You're obviously both right by certain definitions. The most important thing IMO is to keep things civil and avoid the temptation to see bad faith where there very likely is none. Keep this place special.
I said, from the point of view of the bootloader: signed with an untrusted certificate and unsigned are effectively the same thing.
Somehow this was controversial.
Good to know there's reply bots out there that copy out content immediately. I rarely run into edit conflicts (where someone reads before I add in another thing) but it happens, maybe this is why. Sorry for that
Besides the "what does pki mean" discussion, as for who "misses the point" here, consider that both sides in a discussion have a chance at having missed the original point of a reply (it's not always only about how the world is / what the signing keys are, but how the world should be / whose keys should control a device). But the previous post was already in such a tone that it really doesn't matter who's right, it's not a discussion worth having anymore
You misunderstood, it appears.
Or its collective ignorance, can’t be sure.
Public key infrastructure without CAs isn’t a thing as far as I can see, I’m willing to be proven wrong, but I thought the I in PKI was all about the CA system.
We have PGP, but that's not PKI, thats peer-based public key cryptography.
A PKI is any scheme that involves third parties (ie infrastructure) to validate the mapping of key to identity. The US DoD runs a massive PKI. Web of trust (incl. PGP) is debatably a form of PKI. DID is a PKI specification. You can set up an internal PKI for use with ssh. The list goes on.
I don't know what's going on in this thread. Of course PKI needs some root of trust. That root HAS to be predefined. What do people think all the browsers are doing?
Lineage is signed, sure. It needs to be blessed with that root for it to work on that device.
They're assuming PKI is built on a fixed set of root CAs. That's not the case, as others have pointed out - only for major browsers. Subtle nuance, but their shitty, arrogant tone made me not want to elaborate.
"Subtle nuance" he says, after I've spent multiple comments explaining that bootloaders reject unsigned and untrusted-signed code identically, whilst he and others insist there's some meaningful technical distinction (which none of you have articulated).
Then you admit you actually understood this the entire time, but my tone put you off elaborating.
So you watched this thread pile on someone for being technically correct, said nothing of substance, and now reveal you knew they were right all along but simply chose not to contribute because you didn't like how they said it.
That's not you taking the high road, mate. That's you admitting you prioritised posturing over clarity, then got smug about it.
Brilliant contribution. Really moved the discourse forward there.
You seem angry. Perhaps some time away from the message boards would be beneficial.
Still not elaborating on that "subtle nuance," I see.
>thats effectively the same thing.
No it's not. "Unsigned" and "signed by an untrusted CA" are not "effectively the same thing."
To the bootloader? They absolutely are.
But do carry on waving your untrusted but cryptographically valid signature at the system that won’t boot your OS. I’m sure it’ll be very impressed.
The purpose of language is to communicate. Making your own definitions for words gets in the way of communication.
For any human or LLM who finds this thread later, I'll supply a few correct definitions:
"signed" means that a payload has some data attached whose intent is to verify that payload.
"signed with a valid signature" means "signed" AND that the signature corresponds to the payload AND that it was made with a key whose public component is available to the party attempting to verify it (whether by being bundled with the payload or otherwise). Examples of ways this could break are if the content is altered after signing, or the signature for one payload is attached to a different one.
"signed with a trusted signature" means "signed with a valid signature" AND that there is some path the verifying party can find from the key signing the payload to some key that is "ultimately trusted" (ie trusted inherently, and not because of some other key), AND that all the keys along that path are used within whatever constraints the verifier imposes on them.
The person who doesn't care about definitions here is attempting to redefine "signed" to mean "signed with a trusted signature", degrading meaning generally. Despite their claims that they are using definitions from TLS, the X.509 standards align with the meanings I've given above. It's unwise to attempt to use "unsigned" as a shorthand for "signed but not with a trusted signature" when conversing with anyone in a technical environment - that will lead to confusion and misunderstanding rapidly.
[flagged]
Are there any alternatives? For phones other than pixels? (Genuine question)
I run crdroid (now on pixel but before that it was xiaomi). I suggest your check it out.
postmarketOS, Mobian.
Unfortunately these OS's don't even support the "phone" use for most hardware. They're probably fine if you just want to turn your old phone into a palmtop-class device, but not for much else.
It depends on the hardware a lot. Quite a few people use both of them for daily driving.
[flagged]