quotemstr
Microcosm of Pivot itself I guess. I just don't get why this project exists when DuckDB and Clickhouse both exist.
That's because RuBisCO is a terrible enzyme that only barely works; photosynthesis works better the more CO2 you feed it. RuBisCO actually evolved in a higher-CO2 atmosphere and is optimized for that one, not ours. Terrestrial plants today are basically an alien species trying to adapt to a marginally (from their POV) frontier planet.
Now, you could argue that this climate model or that climate model increase net productivity once you take into account land use patterns, population shifts, blah blah blah. You can make these models say whatever you want them to say. Truth is, biomechanically, more CO2 means higher yields with same inputs on the same land, and we are very good at making land suitable for agriculture.
The heroic efforts of early industrialists adding carbon to the atmosphere avoided this calamity and set us up with a level of comfy and productive climate unknown in the quaternary.
Amazing how humanity keeps lucking out like this.
The way to stop the vulnerability apocalypse is to fix the vulnerabilities, not to shoot the damn messengers.
I hope someone abliterates and FTs this model on vulnerability discovery so we can find more bugs in our testing, insecure tech stacks.
A human being, presumably. But he could be a dog or a diffusion model and I wouldn't care, because arguments stand on their own. There is no special caste of people who alone have permission to propose ideas.
You advocate critical thinking. Excellent. Can you critically evaluate "Elias Taylor"'s argument?
I just fundamentally disagree with Google on how to evolve data structures. Sloppy open-domain protobuf field presence, enum values, whatever are illusory extension points. Better to have discrete versions of a data structure --- Foo1, Foo2, Foo3, etc., and rigid checking in each one than to have just one "Foo" with optional-everything that changes implicitly over time.
He is, in fact, not mitigating the attack, and he is, in fact, by calling his non-workaround a mitigation, encouraging people to do ineffective things instead of patching. These facts remain true in the real world regardless of what you call a personal attack.
And yes, San Francisco has become top of the world for indirect fake kindness that transforms plain factual statements about the world into social offenses.
"The sun is bright. Don't look at it " -- RUDE!
"You might want to consider that the sun might be considered bright to some people and that you might be more comfortable looking at this other cool thing instead. But no pressure" -- gruff, barely tolerable
Unless your position that any statement whatsoever made in the second person that isn't a compliment is then an attack?
San Francisco is a magical place where "you are doing X wrong" without slathering on six paragraphs of fake kindness constitutes some kind of personal attack
An attacker with a compromised certificate MITMs the site, terminates and proxies TLS using the bad certificate, and the TLS UA never sees that it's supposed to enforce DANE too?
That's what ExtSupportLifetime is for. Other pinning approaches, e.g. HSTS-like preload lists, work too. Union them. You need only one of N mechanisms to say "my domain promises to staple DNSSEC" to make the browser expect it and fail hard if it's not there. But stapling is just a transitional measure anyway.
The better solution, of course, is to just fix DNSSEC so the problem doesn't occur in the first place. There's no need to staple and no opportunity to strip if you can verify the DNS resolution end to end.
So, in this "doesn't work" scenario, it just so happens that the very first client contact endpoint is via this MITM, and the certificate is compromised at this moment, and HSTS or something prevents stripping TLS entirely, and the endpoint isn't on a DANE preload list (although it is on the HSTS one!) and DNSSEC isn't working in the client's environment? All at once?
Yeah, right.
Who's going to use HSTS, and DANE, but not set the "I'm using DANE" bit in the HSTS config? And if you're not using HSTS, an attacker can just strip TLS anyway and you lose regardless.
So yeah, it does work, and the "doesn't work" failure mode is server misconfiguration.
I'm 90% sure CGI can't be exploited this way in default configuration with ASLR and 99% sure if PHP is configured with memory_limit=-1
That said, don't be an idiot and switch to CGI instead of patching. I'm like one of three guys running PHP in CGI mode and I'm vaguely satisfied I have the most resistant configuration.
The reason, BTW, I run PHP in CGI mode is so I can (moral equivalent of) suexec to a locked-down sandboxed environment that limits exploit blast radius. I could do the same with fcgi daemon, but the suexec is stateless, and roundcube doesn't need the performance.
In general, anything stateful or long-lived is just one more thing that can go wrong. One reason why the trend of turning everything into a persistent daemon drives me nuts.
This way, fuckups like this CA can't hurt me because they couldn't break DANE and IC couldn't hurt me (more than they can already) because WebPKI would have to approve too.
I don't think the CA death penalty addresses the problem. Just as in the physical world, the death penalty isn't a perfect deterrent.
In a DANE world, I need only trust the DNS authorities, and there are ways to boost trust in, e.g. the dot-com key management. (Could even go full ring signatures if we wanted.)
Someone over on foo.wtf.lol can't hurt me.
In general, email has used DNS to a greater extent than the web has to build trust mechanisms that don't depend on giant lists managed by a tiny number of browser vendors.