Hacker News Reader

Comment by jeffbee | Hacker News Reader

It's interesting that this sort of policy is baked into a language platform.

It's basically an additional policy on top your OS's policy, while waiting for the stores to update, it protects the users.

Or allows Google to override security. They could also trust a certificate here, maybe one owned by the regime.

How would that even make any sense for an open source project that people expect goodwill from?

Why expect goodwill from Google?

There are links to pretty readable changesets, so you can go read and understand exactly what's happening instead of speculating.

you both pin your compiler version, and your binaries are compiled so it only affects going forwards

Indeed. But the Java keystore and the Firefox/Chrome/VSCode NSSDB and whatever Python is shipping this week aren't really better.

I wonder what's so annoying about OS certs.

It's mostly historical. They used to suck in the past, but the implementations remain. Nowadays you are better off configuring to use OS certificates if possible.

I really appreciate Firefox to have their own certificate DB because it allows to create separate profiles with different trusted certificate sets. The country where I live issued it's own root certificates which I have reasons not to trust in all cases but when accessing government services etc. So I've created a separate Firefox profile where I've installed those malicious certificates, keeping the main Firefox profile clean.

It's nice that firefox implemented that but it's the wrong place to do it IMO. It's the sort of thing that should be built into the OS along with fine grained permissions and sandboxing. The browser is merely providing a bandaid over a deficiency.

Yes, as I understand it, this sort of problem is what “Name Constraints”[0] were designed to solve. (Well, really, they were intended to be used with corporate internal CAs[1], but there's no reason they wouldn't work more broadly, too.)

[0]: https://www.rfc-editor.org/info/rfc5280/#section-4.2.1.10 [1]: https://utcc.utoronto.ca/~cks/space/blog/tech/TLSInternalCAN...

At least it kind of makes for them specifically, since Netscape did SSL initially before OSes had that functionality. Their mailing list, as far as I know, is still the canonical place for public discussion about the infrastructure.

Firefox is a browser so it make sense to implement their TLS like that.

But we're talking about a lib of a programming language here, things happened in there effects your own reputation when you ship something built on top of it.

So the real question is, has others such as OpenSSL done the same? If yes, then yeah it's normal, but if no then I don't trust people from Google.

What about it makes it so interesting?

Clearly the platform isn't designed to do this. Nobody thought this was going to be a necessary facility. They have just crammed an array of numbers as literal values deep into the standard library. So clearly this is an exceptional event, and not the exercise of a feature that was foreseen.

Ah, yes that seems to be what URGENT track self-documents as.

One of those "temporary workarounds" that live forever once added?

node is doing the same: https://github.com/nodejs/node/pull/66871

If you don't bundle certificates, users will report that your builtin https client doesn't work in production (usually in docker)

This is already the case for Go.

"interesting" in the same way that folks in the south say "Bless your heart".

It's probably about power. Certs control is getting higher value, so control over this policy means more negotiation power with whatever states (governments) need from platforms.

It's easy to imagine something like: "give us some grant taxpayers money and we'll add your cert to our trusted list/remove theirs cert/disable cert when run on this hardware/etc."

Reply on news.ycombinator.com