This does not involve designing and implementing a fancy user interface. It only needs the bare minimum of a functional interface for driving the installation process.
There's the open source fastboot code and an existing proprietary WebUSB-based flasher to reverse engineer.
Conversation
Need to be comfortable with straightforward, fairly modern C++ and with JavaScript.
UX design and CSS are not within the scope of the project. Don't need to be concerned with making usable instructions either.
Goal for the project is a working installer with a bare minimum UI.
1
4
10
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.
1
2
10
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.
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.
3
Show replies
That’s understandable. Still, chaining back to an OS trust anchor would be nice, especially for less technical users.