github.com/webadb/webadb. has the start of a fastboot protocol implementation. It can likely already be used to issue the lock and unlock commands without much work.
Project involves figuring out how to do the rest of the flashing commands and putting it together as an installer.
Conversation
No real need for existing experience with Android development. It's quite standalone.
Don't need to already have a usable phone for working on this since we can buy one as part of the funding.
The result will be open source and usable with other devices and operating systems.
1
1
13
This will be turned into an easy to use graphical installer for GrapheneOS not requiring software beyond a browser and our site.
CLI instructions will still be recommended for technical users on an OS with proper fastboot and signify packages. Otherwise, WebUSB makes more sense.
2
1
19
Replying to
What about code-signed macOS and Windows executables? That would be more work, and I understand if the funding for that isn’t there, but it would be more secure than a web site.
1
Another idea I had was to make an installer package for Linux distros. It would be a wrapper script that downloaded, verified, and ran the needed components on the fly.
1
Trusting an installer downloaded from the site without verifying it with our offline signing key for the factory images is equivalent to trusting the site, but with a lot more that can go wrong. Could just release an archive with the web installer that's signed instead of that.
2
That’s a good idea. That said, I was referring to macOS and Windows code-signing with X.509 certificates. That would provide users of those OSs with a chain of trust back to an anchor provided with the OS.
1
My assumption is that code-signing certificates are less likely to be mississued than TLS certificates, so this provides a higher degree of assurance. The actual flashing could be done via WebUSB in a browser instance running from file:// with addons disabled.
2
We'd rather have people verify with signify or another utility like certutil on Windows and a specific public key they can obtain from multiple locations. Can see that's how we provide the signify public key for the factory images in our CLI installation guide. Multiple sources.
2
Code signing certificates aren't hard to obtain. WebPKI isn't very good but we do have DANE TLSA records for all of our TLS services including the web sites and it's possible to check that it matches the certificate. It's unfortunate that browsers don't do it automatically.
2
We could publish the DANE TLSA records elsewhere too rather than only being able to obtain them via DNS with verification via DNSSEC. The advantage of signify for the factory images is that it's an offline signing key not available to the server, like the actual OS signing keys.
Speaking of server security: I seem to remember that GrapheneOS uses OVH for hosting. How do you ensure the security of your servers at OVH? My main worry with a service like OVH is firmware attacks.
The important thing is to not make the mistake of HPKP and have clients maintain long-term caches of pins. The reason DANE is viable, is that the data is published by the server operator and has a short TTL. The transport need not be DNS, but hard say what alternatives are viable
1
But indeed it is possible to deliver TLSA records by various other means, and OpenSSL implements DANE in a manner that's transport agnostic, you provide the TLSA records to the library and ask it to verify a cert chain, how you got them is up to you.