We primarily focused on privacy aspects, but we are definitely interested in increasing the security level too. I won’t comment the “security decreased by Lineage” claim: this is a point of vue that one can share or not. But, each commit submitted to inclusion in official Lineage sources is carefully reviewed by several people, and it’s generally a long run before it is accepted. Security aspects are of course among the criteria for acceptance.
about release mode: indeed, userdebug is the default Lineage build mode and we kept it. It does not lower security of the device, unless the user itself enables adb, and a fortiori adb root. And only a physical access to the device can lead to a security breach, if the user enabled adb root, and a computer can be connected (the phone must be unlocked to accept the connection, …).
Anyway, we are actually investigating user (aka release) builds, more for usability aspects (to make e.g. more banking apps to work) than for security aspects.
binaries/builds are signed, and an OTA won’t be made if keys do not match. OTA updates are actually stored on github and accessed through https, so we can I think consider that it has reasonable security level.
kernel security updates: we don’t do anything more than actual Lineage device maintainers. We will probably work on this aspect in the future, probably mainly by looking at the DivestOS approach, but it is not planned in the short term.
About other security aspects like the ones in DivestOS and Graphene: same answer, we plan to have a closer look and gradually increase the security level of iodé, in the mid/long-term.
Some of these statements sound very worrisome to me:
“security decreased by Lineage” claim: this is a point of vue[sic] that one can share or not: this does not make sense. Something is either secure or it is not, it’s no belief. What can vary however is the security model one is interested in and on which the outcome (secure or not secure) will be based.
We primarily focused on privacy aspects, but we are definitely interested in increasing the security level too.: Security is prerequisite to privacy. (Privacy is defined by your security model. Breaking the security of a DNS implementation will break a certain definition of privacy.)
OTA updates are actually stored on github and accessed through https, so we can I think consider that it has reasonable security level.: What is https actually supposed to bring in terms of security?
who are “we”? I did not find much information behind the iodé os entity. It’s a very nice security feature to have the builds signed by a trusted entity. Can we (the users going to flash iodé os) trust this entity?
Best, and looking forward to your great contributions to more security (and then privacy!)
One general comment from my side.
You can have security without privacy (Android stock rom, iOS, …) BUT you can’t have privacy without security (that is nonsense from security point of view).
So, I am strongly suggesting iodé to invest in the topics mentioned above.
Using an https server for retrieving OTA updates is not enough. A security download mechanism shall be set in place to verify the update is done by iodé and by nobody else.
Of course security is important, and we’ll progress on that side ; although as I maintain, increasing privacy level is our priority and where we put the most effort. AOSP/Lineageos already has a good security level, but a poor privacy one: privacy is more compromised than security by a big factor. With classical google phones, the privacy of all users is constantly compromised!
As I previously explained, OTA updates are completely secure. The packages are signed by us, with a public/private key pair, and a compromised one won’t install as the keys cannot match. Btw point 4. above, builds signed by a trusted entity, is a nonsense. Our builds are perfectly authenticated with a public key, included in the rom, that matches the private key that only belongs to us, used to sign the builds. How could our builds be signed by an external trusted entity ?? We are the (hopefully, at least by some users) trusted entity behind iodeOS.