Hi. Guy who does the autoscaling code here at Epic. It's really fun to watch the graphs of how many server sessions we have in a region at any given time over the course of a day.
You can't flash the firmware yourself, as the keys are discarded as soon as they're generated per device.
What you could do, however, is read the bits off of the firmware and make sure they're identical to the bits you make from source. Reproducible builds, and all that.
That's the current state of affairs. I know of no baseband manufacturer who has ever offered (nor seemed open to the idea of releasing) source for their chips.
Basebands aside, the rest of the device is somewhat feasible to see being open.
Unless there is a bug in their hardware implementation of AES-CCM or (shudder) some sort of crazy disclosure vulnerability in the APIs they provide, there is (presumably) no way to get at the UID. Even if you were to decap the chip and get at the UID physically, you still aren't any better off as it derives the actual encryption key on boot from the UID.
The Secure Enclave is essentially a hardware security module, in more general terms. The only thing that leaves its boundaries are the results of crypto operations, not the parameters that went into calculating them.
Despite the openness of Android/AOSP, there are still, unfortunately, things like binary blobs for certain graphics chips and closed-source firmware for things like Wi-Fi chipsets. Given what we've seen agencies like NSA are capable of (intercepting hardware in transit to apply backdoors, paying off RSA to make Dual EC the default pRNG in their crypto libraries, etc.), them compelling a manufacturer of a component to include a backdoor in their closed-source blobs is no stretch of the imagination.
Apple even has this problem: basebands in cellular modems are notorious for being the source of exploits in otherwise-secure phones.
A number of developers from RedHat were once very involved in the project. However, these developers had a very arrogant attitude towards Docker: They wanted docker changed so that it would follow their design ideas for RHEL and systemd. They often made pull requests with poorly written and undocumented code and then they became very agressive when those pull requests were not accepted, saying "we need this change we will ship a patched version of Docker and cause you problems on RHEL if you don't make this change in master." They were arogant and agressive, when at the same time, they had the choice of working with the Docker developers and writting quality code that could actually be merged.
THIS. It was both amusing and sad to watch this happen time and time again. My favorite is what happened (or, rather, didn't happen) around CoW filesystems and how they decided to just use a FUSE-based one instead.
(I work at Epic on Team Online, aka the team that this whole PM is about.)