Watermelon And it's why it's noteworthy to mention if many antivirus vendors detect it, but not noteworthy if none detect it.
not my POV. yes, it is true that this is not something you should rely on alone, that's what I said already but when analyzing such issues one has to consider every aspect because every detail counts. it was not meant to be a single proof for it just one part of the research. putting things all together is the key when doing researches like that. if you do not include malware detection in your research you miss an indicator. as said before, everything must be taken into account not just a single thing, at least that is how I do it. sorry if that sounded like the only proof for being "free of malware".
Watermelon Pre-rooting with MAGISK seemingless within the AOSP build process while keeping AVB / DM-VERITY intact !
ah well, then I know where the misunderstanding might come from. ppl might interpret that as it would ENABLE it but that is not the case. it "just" means that it won't get unusable with that (if the device/OS supports it). it does not disable verified boot and it still allows to lock the bootloader keeping the whole chain intact (as long as the device/OS supports it).
Watermelon And bootloader locking is primarily meant for enabling verified boot.
every barrier helps imho. and locking the bootloader helps if someone has physical access to the device in any case. no fastboot cmds possible etc. I do not say it replaces essentials like verified boot or encryption but for me security also includes the physical part. if I can close a window (even if it is that small) I do so.
Watermelon Fairphone 4 doesn't support verified boot
it does - but well.. the thing is the Fairphone allows to boot images signed by test keys (turning that feature into a joke). I found that out when bringing up the FP3 first and now as shown in your link it turns out they still did the same for the FP4. wow.. I have added that one to the projects FP4 known issues, too. Thanks! and what a mess..
Watermelon What are these patches and exploit mitigations supposed to defend against?
If the OS is pre-rooted and an app is granted root access, what is there to defend against?
first of all: being pre-rooted in AXP.OS Pro means not it is activated by default. it must be explicitly enabled first and before that it cannot be used at all (no su, no apps can request root etc). Enabling root in the Pro variant is meant for ppl using their device with extra care and ofc following the known precautions (not clicking dubious links, installing APKs from random sites, etc), rooted or not.
patches and exploit mitigation are useful to make things harder even on a rooted device. I do not say that this is like an ultra extra protection but script kiddies with pre-made exploits won't be able to use these when the OS is patched unless they really know what to do (assuming the attacker has access, has root). even then it might help in getting detected at least (if exploits fail due to OS patches) and making custom exploits harder etc.
as said this is not meant to be a real protection for serious attackers but whatever is possible should be done, imho.
the demand for root is there, for example because there is still no reliable way backing up all apps (+ their data) on a Android device. Yes I am aware of SeedVault (and all its disadvantages and buggy behavior, at least on A13 and lower) but that is just one example why one might want to have it.
AXP.OS Pro reduces risks as much as possible, which differs drastically between root access and no root access – but it is certainly not useless. In any case it is a "better-than-doing-nothing" - approach, even when root is enabled. AXP.OS Slim reduces the risks much more while even there it is the same approach at the end. if a device does not provide firmware fixes AXP.OS cannot protect against that either but it does everything possible to reduce the risks.
Watermelon How does the user know which app developers are trustworthy enough to grant them root access?
how does a user know which app is trustworthy - at all? is Google trustworthy enough? or Graphene? they all can potentially contain such things you mentioned, root or not, wanted or not. Of course with a rooted device the risks are dramatically higher, I don't deny that.
if a user activates root this is the risk he/she has to take. I love freedom of choice. and this includes the possibility to do with a device as I would really own it actually. which includes root. and due to that (freedom of choice) also the Slim flavor exists as users can choose if they want to follow that route or use the pure DivestOS approach (aka AXP.OS Slim).
Look at Apple, they know what is the best for their users and so take the decisions for them what you can do, what not and how they are allowed to do things. same with GNOME when they removed almost all configuration options (to mention just 2).
I don't like decisions being forced upon me (even more if I have a choice). That is why I would like to give people the freedom to choose, naturally taking into account all the advantages and disadvantages associated with that choice.
steadfasterX it is clearly stated that for best security you should use a modern (Pixel) phone and switch to GrapheneOS
Watermelon That doesn't mean that AXP.OS Pro with the stated purpose of being a balance between security, privacy, and usability should throw out all security and privacy by being pre-rooted.
The GrapheneOS hint is meant for ppl wanting a real secure device and that was no ref for AXP.OS Pro being a balance between security, privacy and usability. Balance means the system is de-googled* (privacy), deblobbed (privacy), the OS patched (security), verified boot enabled (security), encryption enforced (security), the bootloader can be locked (security), selinux enforced (security), while still be able to make the most out of it (usability), like even using Google apps - if wanted and explicitly enabled. Of course not all devices support locking the bootloader and/or verified boot as mentioned. Nevertheless, it should be up to users to decide which path to take, i.e., freedom of choice, as I said.
*in terms of calling home on Pro and completely on Slim. Pro comes with MicroG+Play pre-installed while Slim not but both have standard calls to e.g. Google and others like QualComm removed, mainly handled by the deblobber and several patches.
btw: many people think that infections of malware happen out of nowhere but that is rare. Most infections are possible just because of user actions, so the human is the main gateway here. You can buy and enable a lot of technical prevention, malware scan, behavior & bot detection, doing all these in hard and software, scan SSL traffic etc. but at the end the human is the key for a successful infection. This is my experience but also by many others. What I want to say is even if you use e.g. GrapheneOS and do all things technically possible, there is always a way which can catch a human at a bad day, extreme personalized mail and it's done.
No, I don't compare GrapheneOS with AXP.OS, as said. It is just not everyone can effort a modern device or want to make use of legacy devices instead of throwing it in the trash. AXP.OS enables the reuse of such devices. It is the users choice if he/she wants to take the risk using Pro or Slim as a daily driver or not like it is with any custom OS.
Watermelon Even a secure hash algorithm might not provide security, depending on the website configuration and HTTPS/TLS support.
hash algorithms for files are not meant to be for security (imho, and yes I am aware that many think different which is only partly true). for me they are just for file integrity which can be kind of security of course (but no, not if taken it seriously*). so mainly meant for detecting if a file gets corrupted during the download (bad transfer, disk etc).
the only reliable way for security in that regard (regardless of the transport method) is securely signing the file itself or its hash sum file (which is the ideal mix), imo. that way (in the hope the signer protects his/her signing keys and using them offline) we still cannot be 100% safe but at least that's the most practical barrier possible. As always and as you know, the aim is to reduce risks, as there is no such thing as 100% security.
*the server could have been compromised and providing a valid (compromised) sha512 as download / on the website. for me hash sums (if unsigned) are not a real security measure at all (and likely the reason why I still provided md5 sums for my fun project "mAid" at that time). as said I will do better with the next release though.
Watermelon As I said, I don't think you're doing it out of malice
true, you just said that I am incompetent, a fool and have zero security knowledge ;)
Yes, not exactly like that, but that is the essence that I (and probably others) derive from the sometimes overly explicit statements.
Yes, I provided MD5 hashes for my (not AXP.OS related) fun project mAid and I have to admit that I should have changed that earlier as we all know why. That's on me for sure. As mentioned earlier even sha512 sums are not something you can rely on alone. That is why AXP.OS hash files are sha512 + signed and the reason why that will happen with mAid soon, too.
Watermelon And I and another person I know have used mAid and liked it.
I'm really glad to hear that, because that's exactly what it was intended for - to be useful, hopefully.
Watermelon [...] to install mAid and use it as a primary desktop OS [..]
btw (not that you will care but still want to mention it at least): installing mAid should be done from a nightly anyways (which were available at that time as well and included any later XZ package).
I might remove the installer completely from the stable ones because a nightly is always more recent (and so require much less download volume during the installation) and also usually fixes upstream (installation-related) issues.