Transparency: What about project mainline/Google System Update and EOL for drivers/HAL/firmware

Using /e/OS User Queries
1

While I like the principles of /e/OS and appreciate your effort as well as the efforts of Lineage/Cyanogen mod I miss important answers/remarks:

  1. What about project mainline/Google System Update - System updates that come via Google services? Since a few years some core fragments are updated via Google services, especially the media framework which has a “proud” history of security issues (e.g. stagefright vulns). How does /e/OS handle such updates? Are the included in OTA-updates? Does /e/OS have similar system updates via the store?

  2. What about hardware components that do no longer get updates by their manufacturers? There have been issues with critical components like CVE-2019-10540 which effect WiFi-chips (or bluetooth or other connectivity hardware) and thereby are exploitable not only by evil apps or websites but without the users having to be tricked at all. Likely such vulns effect chips that do no longer get updates as well. Shouldn’t there be a warning sign for the download of any (official) e/OS/ build, if parts of the hardware are no longer maintained by the manufacturer of the chip?

  3. Some devices listed are not based on Android versions that get security updates anymore. For example nougat = Android 7 is the newest /e/OS for about 30 phones. As of today, Google supports Android 10 and above with security updates in the AOSP. That means that those nougat build did not get any security update for about 3 years. As an example, even your latest build for Galaxy S III is more than 1 year old. There should be a specific big red warning for such builds/devices. (Yes, you have a generic warning above the list of supported devices, but that is very precise. In this list, you do not even mention what “beta” means and just warn about “dev” versions. If you look at the device page it looks like you consider beta being a dev build, but that is a) not the same for all software project and b) hard to understand for non-techy users.)

Thank you.

2

1 - no alt ROM uses the Apex update mechanism for system components (yet?). If you get regular rebuilds of Aosp you get the same. I thought Graphene might have given it a go, but they too use the regular update cadence - build#enabling-updatable-apex-components
2 - a dedicated Security page next to the FAQ should inform at one place, has a vote by me too. Info is too scattered in posts, forum and discussions. Hard to escape the general industry problem. Legislation will come around at last, but that leaves the technical community still without code to BSPs
3 - in another post Manoj today stated old builds will be more prominently marked outdated / not supported

3

This topic was automatically closed after 30 days. New replies are no longer allowed.