woodruffw

Python’s type system has union types (including Option), and using them is pretty ergonomic. As TFA points out the problem is that `None` gets contextually reused in all kinds of places where a proper sentinel type is more appropriate.

> Can you explain your decision?

Not easily, because it's closer to a convergence of smaller engineering decisions into an emergent choice to ship a CA bundle.

But the short version: lots of tools ship their own CA bundle. This is not ideal for distributors like Homebrew, because people expect one CA root program for the entire distribution. As a result, Homebrew tries (and sometimes fails) to apply a consistent root program across its tools. Apple's own roots are not inherently best suited for all Homebrew users, so we end up shipping a composite of their roots and the Mozila root program.

> What happens if they are in disagreement?

They are in disagreement, all the time! Root program operators are totally free to manage their trust roots as they please. The only forcing function is a desire to honor users' connections; differences in root programs end up getting papered over somewhat by cross-signing between different CAs.

I’m currently on mobile but you can look at the source (and Git history) for the ca-certificates formula for the patch.

(Sorry if you thought it was a brag, it’s just supposed to be context so that everybody is on the same page about the reason for a comment.)

Homebrew ships its own CA bundle so its own curl, etc. are not affected. But the system versions of those tools will continue to be affected until Apple patches their own bundle.

Edit: Git is still affected, we're fixing that now.

(Source: I am one of Homebrew’s maintainers.)

PyO3 is an extraordinarily popular project, and there are (tens of?) thousands of Python packages using it. I think we're years past the point of the Rust/Python intersection being small.

uv just turned 3, so "years" feels like a stretch. And I think lock-in is not and has never been a goal of the project. uv generally bends over backwards to conform to Python packaging standards because the people who work on uv also tend to work on those standards. The places where it doesn't (like uv.lock) are because the standards can't express exactly the things uv wants.

(Note: I work on both uv and Python packaging standards.)

> I guess I'd like "uv format" and "uv lint" to become the standard commands.

Note that `uv format` does exist (in an experimental state) and does what you expect w/r/t invoking Ruff. And `uv check` is the equivalent for ty.

(ty is "part of" Ruff in the sense that it shares a lot of the same machinery, so the two are closely joined in terms of source trees. But it's an entirely separate binary from Ruff's.)

I mean, that seems intentional to me.

They don’t appear to, at least not in my reading. “It could not have been designed better” reads more like an indictment of quality than an accusation of malfeasance.

There are two different things here: there’s code that is vulnerable because of unnecessary complexity, and there is imputing malice or an intent to hide exploitability through complexity. OpenSSL exhibits the former, not the latter.

That would be an awfully slow emergence, given the age of the Web PKI.