Sure, you're free to do what you want. Just sharing my opinion given that I follow those projects from the outside.
> You or other readers can check
I guess what I am trying to say is that it takes multiple sides to argue.
For what it's worth, your link shows the founder of /e/OS engaging there. I have seen both technically wrong and misleading claims from the founder of /e/OS on Mastodon, then GrapheneOS explaining why they thought it was wrong on their forum, and then the founder of /e/OS calling them toxic and complaining about those attacks. And then /e/OS users would join the party and start attacking GrapheneOS, fully trusting those claims from the /e/OS founder. I can't really say that he didn't have any responsibility in the drama under those conditions...
Again, GrapheneOS tend to be blunt, but it doesn't make it technically wrong. And when the message is "it is unacceptable to us in terms of security", then it will be blunt anyway. I realised after years of using a phone I bought to Murena that my system (that they installed and sold to me) was entirely breaking the AOSP security model: it was signed with the Google testing keys and the bootloader was unlocked (and just couldn't be relocked, and anyway it wouldn't matter because of those keys that are not meant for production).
In other words, I bought a product to Murena that was unacceptable to me in terms of security, but genuinely thought it was better than Stock Android because of Murena / /e/OS marketing. I genuinely feel either they tricked me, or they didn't know it themselves. I have personally seen multiple /e/OS phones in a state where they were objectively less secure than Stock Android. I get that they don't like it when GrapheneOS says it, but that is not wrong.
For the security thing: It is wrong to claim that an unlocked bootloader completely breaks the android security model. If anything, it breaks one specific aspect, one that doesn't matter for many attacker models. Besides, on some phones the bootloader just can't be relocked, that's on the phone vendor though. Signing keys for bootloaders might just not matter if change detection was working or the bootloader was not relockable, but maybe I'm missing some specifics there.
So imho what you describe as catastrophic scenario likely wasn't one.
You seem knowledgeable about this, so I'll take the opportunity to ask: if I install a malicious app and it manages to escape the sandbox and alter the system, my understanding is that it will be detected next time I boot it (because the image hash won't match). Isn't that true?
> Signing keys for bootloaders might just not matter
Again a question, I haven't found it in the official documentation: aren't those keys the "system keys"? As in, if my system is signed with some keys and an app is signed with those same keys, doesn't it allow this app to get privileged permissions?
If a malicious app tries to alter the system in a bootloader relevant way, it would most likely fail. On those roms, apps don't have root rights, and users are even unable to activate a root account (part of why we need unlocked bootloaders in the first place to achieve user control over bought devices). But yes, as part of AVB system parts are hashed and a mismatch would be detected, see https://emteria.com/blog/android-verified-boot for a writeup.
For system apps, again two aspects. It's not that easy for an app to become a system app, it has to be moved to a specific place. Think about how the Gapps package is usually installed when you install a ROM, externally by the recovery system and not inside Android itself, that would be the reason. But yes, there are platform keys that the docs at https://source.android.com/docs/core/ota/sign_builds claim should be secret release keys.
About those release keys being also used for the system app verification, I think so. There are different keys on Android, like the release keys and the verity_key, but I think it follows from the docs that the release key is the one used to verify system apps (on modern Android versions).
It is debatable whether users not being able to exchange system apps then is a valid requirement for a FOSS Android distribution like /e/. But that position does exist, claiming users should build their ROM variants on their own with custom keys if they want to modify the system, to close this attack vector.
They're misrepresenting what has been said by GrapheneOS and also lack a good understanding of it themselves. They're definitely not a good source of information about this.
1. Is it correct that the secure boot protects again a malicious app escaping the sandbox and persisting into the system?
2. Is it correct that if the system is signed with the Google testing keys, then someone could sign an app with those keys and the app would get more permissions than it should (I believe it's called the "signature" permissions)?