creatonez

"swept under the rug with CGNAT" is a really funny way to say "solved by IPv6"

Most virologists are not terrified of gain-of-function research the way the public is...

- 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

Both workloads being malicious and trying to establish a hidden data channel between them probably makes this attack a lot easier than conventional spectre/meltdown where it's trying to target ordinary processes that are not intentionally trying to be loud.

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

The refusal string feature was implemented at an API level, but for whatever reason Anthropic doesn't want the feature to exist anymore. It's gone now, the refusals you get now are just the model's natural behavior, perhaps after being trained on internet posts that mentioned the feature.

Meh. This is the only part that should be boring, because boring prevents mistakes that result in data loss, which ends the fun of gaming faster than any other problem.

Not anymore, because the CT logs only accept entries for currently active certificates. But during the period before it was revoked, yes.

The intent isn't public shaming, it's to have enough information about what the hell happened, so that the failure mode can be squashed as thoroughly as possible in the future. Other CAs and interested parties should be terrified about the possibility that they have the same cockroach infestation as a result of using the same software or similar procedures, rather than sneer about how bad the so-called "human error" was this time.

> At the time of posting, I didn't know about any embargo. My contact had told me there was no embargo, and her contact had told her the same thing.

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.

On second look, I guess I'm wrong about Node.js... shockingly, they follow in Java's idiotic footsteps and do use a builtin root store by default.

Is certifi used widely in the Python ecosystem?

> It appears to me they do, and that is why everybody is saying to patch your python, go, and node infrastructure separately from /etc/ssl.

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)

> * It's absurd that Python, Go, or Node need their own certificate stores that need separate updates.

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.

Huh? Smaller numbers are a smaller part of the space.

> 2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.

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

The certificates are not trusted, they have a certificate revocation from the issuer associated with them. Your OS trusting these certs is a symptom of it not getting an up to date CRL.