I have done security releases before (not in OpenSSL), and the first line we have there is that don't push upstream in the flashiest text possible. In OpenSSL's case, they might share it with other major OSs beforehand (because many software statically link to OpenSSL), but there is always a secure channel in place to make sure the patches/commits are not leaked.
In the unfortunate event that the commits were pushed to a public repository, the most sensible thing to do is to just release the tagged release with the security announcement anyway.
The relevant commits and pull requests are confidential and per OpenSSL's normal operating procedures are only available on an embargoed private fork to embargo participants.
I don't know a lot about C or the internals of OpenSSL, but going by the commit message, does this mean we should disable TLSv1.3 until we've had a chance to patch OpenSSL?
Edit: Actually, reading through the code a few times, maybe TLSv1.2 should be disabled?
I really wish we had some way to protect ourselves until the patch is widely available.
See the other comments for why the parent is wrong.
> I really wish we had some way to protect ourselves until the patch is widely available.
I would hope/expect that the OpenSSL project has no indication that this vulnerability is used in the wild. And that is probably why they preferred announcing a patch date instead of releasing a fix right away. (But I don’t know their policies, so this is just speculation.)
That would mean that you don’t really need to do anything you shouldn’t have already been doing prior to this announcement to protect yourself until the patch is out.
Unless the vulnerability is easy to find — in which case we’d already hear about exploitation attempts, so I don’t think it is — worrying about this is as useful as worrying about the other critical yet-to-be-found vulnerabilities in the software you use (which most certainly exist).
