woodruffw

No problem! I think it's actually pretty funny/interesting how these classifications, which are ultimately mostly socialized/arbitrary, shift over time. These days, there's certainly much less cultural salience to Nichols' executive choices in the film.

The same way someone can look like any ethnic group: there's some genetics, and a much larger heap of stereotypes.

> And why would someone “who looks like him” not be able to live the upscale California life?

It takes place in the 1960s. At that point, American Jews were not as fully assimilated into broader white American culture. That has changed quite a bit in the last 60 years.

(This is a trope from the period, and applies to other groups as well. The wedding scene in The Godfather has a similar message behind it.)

> Somewhat similar to Al Pacino (who isn’t Jewish).

Italians and Jews often look similar because Ashenazim (European Jews) are mostly Southern European i.e. Italian in their admixture[1].

[1]: https://en.wikipedia.org/wiki/Ashkenazi_Jews#Genetics

As Hoffman points out, he looks ethnic, i.e. Jewish. He's pointing out that, in the 1960s, someone who looks like him would absolutely not be named "Benjamin Braddock" or live the kind of stereotypical WASP-y California life depicted in the film. In that sense, he's an unconventional casting choice for the character.

> What the heck does any of this mean? Jewish inside? What?

Nichols is saying that he's made an intentional decision to re-characterize Braddock's character using more stereotypically Jewish qualities. Hoffman's portrayal is anxious and alienated, and this has special resonance with a Jewish audience (particularly in the 1960s) watching a movie that's facially a drama-comedy about polite, WASPy society.

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.

Yes, I realized we have a gap there. I spoke too soon about Git being patched just because our own CA bundle was. My apologies.

There's a fix incoming here[1].

[1]: https://github.com/Homebrew/homebrew-core/pull/321878

Edit: Sorry, I forgot that I had patched my local bundle. This might indeed be an oversight, I'm looking at it now.

Edit 2: This is being fixed now[1]. Everything below is stale.

I couldn't reproduce this:

  % which git
    /opt/homebrew/bin/git
  % git ls-remote https://git-emudhra.we-have-a-problem.com/check.git
    fatal: unable to access 'https://git-emudhra.we-have-a-problem.com/check.git/': SSL certificate problem: unable to get local issuer certificate

Make sure your `git` binary is Homebrew's, not the system/XCode CLT one. If you see `/usr/bin/git`, you're not using the Homebrewed Git.

[1]: https://github.com/Homebrew/homebrew-core/pull/321878

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.

I have a pretty good idea. And it has nothing to do with malice or exploitability.

No, that's not what's being implied. They're just saying they don't understand why OpenSSL has added so many indirections to otherwise straightforward operations.

Source: I am friends with the maintainers who wrote this and was one of the people who reviewed it in draft form.

“Could” is doing a lot of lifting here. Like `d=4`, the parsimonious explanations are honest mistakes, incompetence, and institutional error, not intentional bug placement.

I don’t think the actor’s persona is the most relevant thing here, although I do think that more sophisticated attackers generally don’t prefer open source supply chain attacks because it doesn’t have the right visibility-to-impact ratio.

But again: it’s impossible to argue against a “silent majority” claim. The argument passes the sniff test for drug smuggling because we have separate evidence that most drugs are not interdicted. We have no such separate evidence for open source supply chain compromises.

I think drug smuggling and open source package compromise have pretty different failure modes, which explains differences in perpetrator behavior.

(This is also different from what the GP argues.)

My research did not show “months to years.” Even weeks of presence are an outlying event[1].

(This is a situation where everybody benefits from high quality data. If you have data that contradicts mine, please share it!)

[1]: https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

> From some of them perhaps, but plenty hide for -years- undetected.

Which ones? Not even xz-utils was years (it was weeks), and it’s the poster child for a attacker doing everything right until the very end.

Why would I trust my domain registrar to maintain PKI? They don’t seem inherently better suited for it, and in various ways are more susceptible to meddling for e.g. ccTLDs.

I think the idea that CAs are uniquely incompetent is probably incorrect.

There are a lot of CAs that are essentially grandfathered into root programs (and there’s no “one” root program, every OS and verifier gets to choose their own inclusion policies). They might need to jump through hoops to stay in any given program, but being there in the first place is not a strong indicator of quality.

The trust store refers to the collection of parties that ultimately verify the signed claim of your control over a domain, which might have taken the form of a DNS TXT challenge (or any other number of challenges). You still need it, because there would otherwise be a basic circularity when determining whether to trust a connection.

(Moving the PKI into DNS does not remove it, it just moves it around.)

I feel somewhat confident in speculating that a bunch of people at large companies will, in fact, be auditing the logs following this. That’s their main value; they’re not really an online/active prophylactic.

That’s why I’m talking about it purely in the context of incident response/forensics.