Security is not their top competency, nor mission.
Check out the pages on GrapheneOS.org, definitely seems they're who you're after.
LineageOS's first priority isn't security - it's freedom. Graphene and CalyxOS have security as the first priority - but have only a couple of phones on their support list and they deprecate old devices as soon as they stop receiving vendor updates.
But, importantly, they also care about security, and you'll get security updates faster and more often than with the vendor's stock ROM.
This is sarcasm, to be clear.
(on my device, it is possible to just "fastboot oem lock", but that is aside the point)
What specific security problem does this cause?
> pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.)
This is good for security. Not everyone can afford to get a new phone as soon as the vendor drops support, and just because you can't fix everything doesn't mean that you shouldn't fix what you can.
> ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates)
What's incorrect about it?
> don't support locking the bootloader to enable verified boot on many supported devices
This isn't really their fault. On most devices, relocking the bootloader with anything non-stock has a high chance of permanently hard bricking.
No, it isn't. It's good for reducing e-waste, your security is on the line.
Having the newly shaped and colored Android UI doesn't do anything to fix security issues..
They don't "pretend" anything. They are very clear that, after a device no longer gets kernel/driver updates from the manufacturer, they can only provide OS/framework updates.
> don't support locking the bootloader to enable verified boot on many supported devices
Can you expand on this more? My understanding was that you could do this on Pixel phones, but that no other manufacturer supports adding user keys to the bootloader.
The point is, it's not as secure to run around with this disabled.
No, it's not only about in-person or targeted attacks.
`userdebug` is used to have a few specific debugging capabilities that aren't available on a `user` ROM. Note that this is not the same as the standard `userdebug`, as most security measures that would otherwise get removed are manually reinstated.
> pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.)
So... no security fixes at all are better in your opinion?
> ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates),
Where are you getting this from? Neither F-Droid nor its privileged extension is included in the system.
> don't support locking the bootloader to enable verified boot on many supported devices
There is nothing that inherently prevents you from relocking your bootloader on LineageOS. But technically, something may go wrong at any time, so it neither is officially supported nor endorsed, and the keys necessary for relocking the bootloader are not provided.
If someone wants to, they can always just build LineageOS themselves (with all system modifications built-in, because anything else would break the signature), sign it with their own keys, and reconfigure their bootloader to use that key.
Can you provide evidence for this?
From another subthread:
> They ship userdebug builds as production releases, pretend to support devices past their vendor EOL (which is impossible since Lineage can't provide security updates for firmware etc.), ship the F-Droid Privileged Extension (which uses an incorrect approach to implementing unattended updates), don't support locking the bootloader to enable verified boot on many supported devices, etc..
I don't see any evidence for your claim there.
> From another subthread:
Replied in that one.
If you want to skip paying $150 for a Pixel to use on Graphene or Calyx or something halfway decent, and "just use Lineage how bad could it be", be my guest!
Also, for supported Pixels $150 or less, https://swappa.com only has the Pixel 3a, which loses manufacturer support next month, and the Pixel 4, which loses manufacturer support 6 months from now.
In addition to providing a stable platform to build upon, Android gives additional support to developers in a number of ways. The Android security team looks for potential vulnerabilities in apps and suggests ways to fix those issues. For devices with Google Play, Play Services delivers security updates for critical software libraries, such as OpenSSL, which is used to secure app communications. Android security released a tool for testing SSL (nogotofail) that helps developers find potential security issues on whichever platform they are developing.
Vs.
>Android is designed for users. Users are provided visibility into the permissions requested by each app and control over those permissions. This design includes the expectation that attackers would attempt to perform common attacks, such as social engineering attacks to convince device users to install malware, and attacks on third-party apps on Android. Android was designed to both reduce the probability of these attacks and greatly limit the impact of the attack in the event that it was successful. (Read: Handcuff users to keep them from violating developer expectations and assumptions)
>Android security continues to progress after the device is in the user's hands. Android works with partners and the public to provide patches for any Android device that is continuing to receive security updates. (Read: we work with developers (them again)* to provide patches to devices that are convenient to deliver patches to)
>More information for end users can be found in the Nexus help center, Pixel help center, or your device manufacturer’s help center. (Read: we take no responsibility for explaining how any developer's use of this power is exercised, ask them!)*
>This page outlines the goals of the Android security program, describes the fundamentals of the Android security architecture, and answers the most pertinent questions for system architects and security analysts. It focuses on the security features of Android's core platform and doesn't discuss security issues that are unique to specific apps, such as those related to the browser or SMS app. (Again, even when talking about users, the language drifts back to people we'd lump under developers... who exactly is the User here?)
Then this gem:
>Verified Boot strives to ensure all executed code comes from a trusted source (usually device OEMs), rather than from an attacker or corruption (oh, is corruption where user programs are classed under?).
It establishes a full chain of trust (for whom, OEM's again?), starting from a hardware-protected root of trust to the bootloader (whose root of trust, OEM?), to the boot partition and other verified partitions.
Sorry, but the language used to describe all of this completely lets the cat out of the bag on who the Android community holds to be the true benefactors of your "ownership" of a handset.
https://source.android.com/security/
Straight from the source. Quiet parts emphasized and said out loud by me.
Android is the most transparently User/operator hostile piece of Open Source software I have ever had the misfortune of laying my eyes upon. The fact you basically have to be a developer to list and understand the things you need to do to get anything non-trivial done speaks volumes.