Upgrade boringssl

[jonasfj]

Ran the script.

[HamdaanAliQuatil]

@HamdaanAliQuatil

Amazing that this actually did run and produced a PR.

After digging around, I've found that I cannot get CLA approval for the robot:
https://opensource.google/documentation/reference/cla#troubleshoot

I think this is a non-trivial amount of setup. Sadly, because of this I can't even get it to run CI.

Or maybe CI just refuses to run on PRs created by automation, that might be a thing, because github probably doesn't want cycles :D

#273 (comment)

Continuing this here. Manual commits would create a trust problem. We definitely don't want XZ Utils to repeat.

I think we should be careful not to “solve” the CLA/CI problem by having automation commit as a human maintainer. That would get us past the mechanical blocker, but it weakens the audit trail exactly where we should be strengthening it.

pyca/cryptography seems to do something along these lines with a dedicated boringSSL bot identity rather than the default Actions bot. Architecturally, this is much better than committing as a maintainer.

But this only helps if Google’s CLA process can be taught to trust that bot for narrowly scoped mechanical updates. If there is a way to register or allowlist a dedicated bot identity for this kind of maintenance PR, I think that is probably the right long-term direction.

[jonasfj]

Probably we should figure out the robot issue.

But perhaps we could make a robot that validates that the vendored boringssl code actually comes from the revision we claim it does.

It's not ideal, but it's a LOT better than nothing, reviewing a PR like this sketchy, but if we could rely on a test or bot to verify that third_party/boringssl matches files from tool/REVISION, then we can ignore changes in third_party/boringssl when reviewing and focus on the few other files, which makes it at-least reasonably possible.

Something like that could be a stop gap measure until we get the robots working.

Or we punt it a bit, and focus on fixing bugs, improving tests and documentation, before we add heavy CI jobs.. Probably there might be some refactoring if we want tree shakable native assets, which we would be epic. And eventually, we'll want prebuilt binaries for people without a C compiler, and then we'll really want to care about the robot situation :D