If I attempt to lock the bootloader I get a message saying the phone has been corrupted. I like to understand what is going on so I have a few questions:
Has the phone really been corrupted or is it just that checking software thinks it has? If not then is there anything simple I can do about it?
Does the same thing happen with all A/B phones or is it specific to the FP3?
Are there any other operating systems for an A/B phone that do not provide a native way of rooting but for which this does not happen?
Finally I would like to say that I think there should be some native way of rooting the phone. I realize itās not for all users (donāt say not for mums and dads because Iām 72 and a grandad and none of my kids would ever dream of rooting a phone) but it should be possible, not necessarily easy, to root it.
Before I had this phone I had an FP2 running Fairphone-Open and it was dead easy to root. I was quite disappointed that I got less functionality running an FP3 with /e/-os.
I donāt use root anymore so probably my knowledge isnāt too deep on that matter.
But from the link you provided I see this part
The second method was introduced when Google first released the Google Pixel devices in 2016. These devices came with dual A/B partition system to support seamless updates and removed the recovery partition from the devices completely. So, the first method failed rigorously. This new method involves patching the stock boot image using Magisk and then flashing the patched boot image via Fastboot.
I guess the bold-face part explains why the phone has been corrupted. From what I understood, thatās exactly the thing a locked bootloader protects from.
One thing that made all this easier on the FP2 was that its bootloader wasnāt locked/lockable.
Yes, I see that, but I suspect that the supposed check for corruption involves little more than checking a fingerprint, something like sha256. But whatever it does, using the word ācorruptedā is misleading; āchangedā would be better. Iām all for security but it seems absurd that the user canāt change the lock. Itās a bit like locking all your tools in the garden shed and throwing the key away āfor securityā.
But I suspect that, in reality, the user can change the lock. The key must be stored on the device itself and if you have the device in your hands with root access there must be some way of changing it. Iām not sure how much added security this actually gives against the people who really matter to me. If I go to China and the authorities want to āexamineā my phone, they may well have got this all figured out.
Of course the real answer is to allow routing at the operating system level itself. You can then have the checks that locking the bootloader gives and they will add whatever added security they add.
My own attitude is that I want, at least in principle, complete control over any device I use. Nannyware that wonāt let me do things because it thinks I havenāt wiped my nose properly may be well meaning and may offer some protection, but who is to say that it, itself, has not been patched?
I donāt intend to comment on your expectations/requirements, but I think I have something to add on the technical aspect.
I have no idea about your technical background, so maybe all I write is already known to you, but from those sentences Iād assume you got something wrong (or I didnāt catch your meaning 100%).
First of all I doubt that checking for corruption can be done by a simple sha256 checksum. For that the bootloader would have to know all checksums for all future update images. Iām pretty sure thatās impossible mathematically.
Then about ātheā key. If ātheā key would be stored on the phone Iād assume the whole concept wouldnāt make much sense.
To be sure, I donāt know implementation details, but if at all, Iād assume the verification works with public/private keys. Then, the public key is used by the bootloader to check that the image (or its checksum) was signed with the corresponding private key. Using the public key extracted from the bootloader (if thatās what you meant to say?) wouldnāt help.
I could imagine that the bootloader could be set up in a way so that a user can add their own public key in order to verify images signed with the userās private key (maybe thatās what you wanted?). But Iām not aware that the FP3 is set up like this (IIRC thatās only the case for Google Pixel phones, but here my knowledge isnāt really firm).
Maybe thatās what you meant all along. Just wanted to make sure our understanding matches.
As an aside, I can remember quite vividly going to a lecture on public/private keys way back in the early 70ās. I guess it must have been a fairly new idea then. The reason I remember it so well is that I had a colleague who had a scholarship from the US Navy to do research into the generation of large prime numbers for his doctorate. We all thought the US Navy must be crazy but half way through the lecture it dawned on me why they had done it.
