Hacker News Reader

Comment by bilekas | Hacker News Reader

> The single confirmed vulnerability is going to end up a severity low CVE planned to get published in sync with our pending next curl release 8.21.0 in late June

My mind still cannot understand the quality and refinement that's gone into cURL. It really is the perfect example of something done so right, that people barely think twice about.

View on HN

Easy, it shows what is achievable if there is a high bar for quality in every single line of code that gets commited, reviewed and merged, regardless of the programming language.

However in the days of race to bottom, offshoring for penies, and now LLM powered code generation, this is a quality most companies won't care unless there is liability in place.

> Easy, it shows what is achievable if there is a high bar for quality in every single line of code that gets commited

This is becoming a more and more overlooked/underrated feature. I genuinely believe it would be impossible in any company that depends on shareholder value. I am yet to convince any company I've worked in without bloody hands that we need to solve old tech debt and refactor certain things etc.

Which is liability is relevant, that is the only language shareholders understand.

If you can get that message across the right way, you're a better company man than me. There's always someone more important than me to say 'but this needs to be delivered first'.

Sure, my point was more in general from government level.

Curl and SQLite are my favourite examples of properly engineered, rigourously tested _anything_. It's really philosophical - those projects' contribution requirements demand such rigor, and the maintainers stand by that demand. A non-load-bearing document (not project code) is what makes that possible - very reminiscent of Einstein's thought experiments leading to tangible projects such as GPS or Descartes's belief that all problems can be solved through rational thinking.

Some people must be working on training some models exclusively on high quality OSS code base like curl and SQLite without the noise of low quality training data.

I would do that with 100% local models from scratch.

> My mind still cannot understand the quality and refinement that's gone into cURL. It really is the perfect example of something done so right, that people barely think twice about.

And all that to then end with people doing: "curl ... | bash" and not seeing anything wrong about it. Then they'll deflect about "threat models" and other non-sense.

I leave you your curl-bash, I keep my cryptographically signed packages installer.

I am also a signing fanboi but I have to point out that the security problem of curl into bash is not really addressed by signing. Signing proves that the component was produced by who claimed produced it. It says nothing about that component being legitimate or non-malicious. As long as the curl bash uses TLS it’s going to be pretty similar for all practical purposes.

Reply on news.ycombinator.com