FiloSottile

This is some serious severity inflation.

Skipping CRL checks is not a Critical. A Critical is "whoops we were not checking the signature on the certificates" or "I guess all zeroes is a fine session ticket key" (both happened, the former in wolfSSL, the latter in GnuTLS).

Bypassing chain length limits is... barely a Low? It's definitely not a High.

The DHE one is fun. It'd have been valuable if they spent some tokens figuring out if any open source library would accept those broken parameters. If not, it doesn't really matter. (Another good reason not to negotiate DH parameters ever!)

This sort of breathless outrage rhetoric would be a lot easier to take seriously if it spent even a minute acknowledging the very real risk to users that this is meant to mitigate: tech support scams where people are walked through installing an app that takes over their phone and steals their money, private data, and identity.

You can disagree with the tradeoff, but if you don't acknowledge it you're just doing propaganda.

Personally, I think the 24h cooldown is an excellent compromise to allow user freedom while slowing down attackers sufficiently to mitigate the harm.

Tech is cool, but it's not an end in itself. Serving people should be. And if people are getting hurt, it's not working well, even if those people are not the ones that read Hacker News.

> If we follow this line of thought it would be more secure to only serve sites to consumers through a few "trusted" third parties right?

No.

I did not discover the issue. I just wished to have a rapid and definitive way to test the patch(es).

As far as I know 30 minutes validity is no one's goal, even long term.

The most aggressive plans (not Let's Encrypt's specifically) target 7 day validities.

Sort of.

I like to insist that the PLC Directory collects and distributes updates to highlight how it's different from a database. The latest state of the account is signed by the key that created it, or by a key that succeeded it. The directory can't inject any values, it's just a low-complexity solution for data availability: the "how do I learn about updates" part.

It could decide to hide/reject updates, but then it could just as well be forked and replaced if it did that. If downstream applications decide to get their account updates somewhere else, that's the directory now, without any loss of continuity for the accounts.

You don't get that from a simple database.

One could argue domain registrations, and so did:web, are more of a database controlled by a (large, international) organization than PLC. Plenty of tradeoffs of course.

Oooof, thank you for catching this. This is what I get for writing spec and API before the implementation (which, to be fair, is usually the right order not to lose sight of the broader picture).

Sorry for the confusion, it's indeed the §6.1 binary format. I corrected the spec and post not to claim it's CBOR.

> I understand people are getting slammed and it sucks, but the main result of rejecting them is going to be an increase in full disclosure.

Right, what I'm saying is that letting those bugs go to full disclosure (aka being filed as public issues, like every other bug) would have been a significant damage to user safety a year ago, and it's not anymore.

Thanks for the comment, I was actually hoping to get your take on this! I linked to it from the article.

> Still on Hacker News, Juho Forsén, one of the most prolific reporters of Go security issues, wrote a long interesting comment that makes the argument that instead we should lean harder into trust relationships with individual researchers. It'd certainly be worth it with Juho, in retrospect, but it's unclear if it would pay off often enough, in the same way that training new contributors who might leave the project in a month or two is not always worth it.

TIL about ZFSBootMenu! Still, the whole frood system is significantly less complex than ZFSBootMenu alone.

I’m pretty sure (even just based on the revenue of various SaaS products) that’s not typical, hence “most NDAs”. I’m also sure some require a SCIF, but that’s not most of them.

Your NDAs prohibit emailing a colleague about the e.g. project, or discussing it in a Slack DM with the client, or tracking progress on it in JIRA? You have to do NDA’d work exclusively with local tools or end-to-end encryption? Those are some difficult NDAs!