- BSL4 is really, really stringent, and these requirements and review processes are strictly regulated across the board

- Most modifications researchers are actually capable of, nature is capable of producing something way scarier. Researchers are making tiny tweaks in comparison to the zoonotic exposure in everyday life that has brought us viruses that do things we never imagined

- Most gain of function tweaks weaken some other aspect, for example the way contagiousness and lethality are at odds

- It's considered rather unlikely that COVID-19 came about via gain of function research, despite how much the public wants this to be true

- It is quite useful for research, a lot is learned by doing it

Hidden data channel between cooperating processes is not quite as alarming, but it may have some implications for malware command and control.

If you're not a party to an embargo, and no one told you an embargo even exists... you should not follow the embargo. In fact, you should maybe even consider leaking basic details or challenging the embargo if you are in this situation. In your situation, they had lost information asymmetry before the news got to you. I don't know where people got the idea that unrelated third parties have to follow embargos.

Embargos are not about keeping secrets, they are about the game theory of coordinated disclosure.

Is certifi used widely in the Python ecosystem?

No it is not. As I said, the revoked key IDs is a supplementary list. It is not a root store. They do not add new root keys or transmit any public key material via this path. It may not contain data that is applicable to the root store being used, but it is perfectly permissible to relay a revocation 'out of band' as long as it represents a truly revoked certificate (CRLs and OCSP are out of band in the same sense)

Only in Java is the practice you're describing (full root store bundled with the runtime) widespread. (Edit: Node.js too, apparently)

They don't. They use the OS certificate store, which on all platforms has already had this certificate revoked from it.

These runtimes are just doing this as a secondary precaution to deliver the revocations to anyone paying attention to version numbers for their runtime but not their OS. It's a bit of an odd approach, and for most of these projects it's their first time ever doing such a thing, but there's no big issue with it as long as it doesn't encourage complacency and is only applied to truly revoked certificates.

You are thinking of Java, which does actually have its own certificate store. Java users are familiar with how wacky this is, so there have been 3rd party attempts at a cleaner solution, such as the way RHEL keeps the Java certificates in sync with the system certificates.

This suggestion seems to be a symptom of thinking different TLDs represent different levels of trustworthiness... which hasn't been the case in ages

And maybe we should stop touching political timezones by then anyways.

But of course, the only scenarios where you have prior knowledge are things like reverse proxies or custom made clients.

This is grade A horseshit. The end goal is for enterprise passkey managers to not boot up at all and not unlock their encrypted stores if hardware attestation isn't available. There's no use in attesting a certain password manager vendor if the platform isn't helping to avoid impersonation.