Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SQLite Critical CVEs or LLM Slop?

research.jfrog.com

Post reply on HN
Print view View original

401–407 of 407 posts

Re: SQLite Critical CVEs or LLM Slop?

#401

Post by tripzilch »

afavour wrote: post #320
ryan_n wrote: post #264

Earlier quoted context omitted.

What fields do you see devs think they know about? I’ve never personally seen this with other devs I work with but obviously small sample size…

In my experience, product. There’s a pervasive view that product is easy, that anyone working in it is a dunderhead who gets in the way of engineers doing the really worthwhile work. In reality, it would just mean they rewrite the software five times and have zero customers. Oh, design too. I’ve met many engineers who simply don’t see any value in design.

Just to flip this around and widen your view, but not everybody's idea of "worthwhile work" is measured by how many customers they have.

Note I can make this claim without calling anyone "arrogant", a "dunderhead" or even go as far as to imply they operate outside of "reality".

Re: SQLite Critical CVEs or LLM Slop?

#402

Post by treszkai »

gortok wrote: post #151
red75prime wrote: post #139

Earlier quoted context omitted.

Apophatic intelligence? "We don't know what intelligence is, but LLMs with CoT are certainly not it despite being Turing-complete." Watching for unexpected failure modes is surely worth it.

Turing-completeness is a necessary pre-requisite for being able to fulfill the requirements of a Turing machine, nothing more. In the same way that cell division is a necessary condition for life, but cell division does not mean a given life form itself is sentient. Intelligent life-forms can generate probabilistic outputs based on inputs, but being able to generate probabilistic outputs based on inputs is not what m…

And similarly, humans are not Turing-complete either: none of us can even in theory sit down and store a trillion bits of information in their mind (or paper, whatever) without loss and without a computer.

So Turing-completeness is not even a necessary condition for intelligence.

Re: SQLite Critical CVEs or LLM Slop?

#403

Post by emj »

pixl97 wrote: post #196
stackghost wrote: post #150

Earlier quoted context omitted.

>all you get is the possibility to [...] execute code Anyone who's ever done even a beginner CTF knows that achieving code execution is a big deal.

Yep, once you have code execution you find a local privilege escalation and go from there.

The point is you can not trust that people patch stuff like this in time. So practically you have to make it really hard, in a CTF of course it is easy. Defense is in depth. There are architectural issues, e.g. we only allow one upload per instance., and sanitation is done away from initial upload handling and processing. I would say that even local root is not that bad if you play your cards correctly. (What ever root mean nowdays with CAP dropping etc)

Enterprise security can be good if people are paranoid when they build the infra, but as is highlighted in this thread many patch requirements are stupid.

Re: SQLite Critical CVEs or LLM Slop?

#404

Post by mike_hock »

inigyou wrote: post #121
mike_hock wrote: post #49

Earlier quoted context omitted.

It's not actually vulnerable. You're absolutely right. I made a critical error. It's NOT vulnerable. It' actually vulnerable. You're absolutely right. I made a critical error. It IS vulnerable. It's not actually vulnerable. You're absolutely right. I made a critical error. It's NOT vulnerable.

Hilariously, this comment tripped the LLM writing filter and was auto-deaded. I vouched for it.

Thanks, I guess :D

Re: SQLite Critical CVEs or LLM Slop?

#405

Post by impartshadow »

batshit_beaver wrote: post #317
adjfasn47573 wrote: post #243

Earlier quoted context omitted.

> A human must verify everything an LLM presents as fact. Everything. I've thought about this for quite some time now. No. A human doesn't need to verify everything. And the argument is really simple: stochastic. Think of self-driving cars: We can show today - based on evidence and real data - that self-driving cars are safer than human drivers. That's a fact and the consequences are clear, more self-driving cars, le…

> Now back to AI for software creation. "Review is the bottleneck because EVERYTHING must be judged by a human." No. It doesn't. We just need to build AI review systems, that will do reviews better than (or at least as good as) humans. The human review quality bar is far below 100%. Far far far. If we can show (likely in the next 12-24 months I think) that AI review quality is consistently above the human review qual…

[flagged]

Re: SQLite Critical CVEs or LLM Slop?

#406

Post by vrighter »

SoftTalker wrote: post #178
vrighter wrote: post #64

Earlier quoted context omitted.

I have been given a list by security. "We had an automated tool scan that machine. It reported these. Fix anything medium severity and above. Never mind that some of them involved vulnerabilities in some part of the bluetooth stack (servers in our datacenter don't even have bluetooth). But they just didn't care

So run apt full-upgrade and get the new bluetooth driver. Why bother with a fight over something that isn't even used? Just do the quickest thing to get it off your plate.

yeah that didn't work. Some apps required particular runtimes to use. We installed those versions in /opt and used them only for the apps that absolutely needed them.

Scanner still said "there's an old shared library in that directory"

Re: SQLite Critical CVEs or LLM Slop?

#407

Post by vrighter »

icedchai wrote: post #365
pixl97 wrote: post #274

Earlier quoted context omitted.

Really the days of "Lets run this stable configuration forever" are gone. Getting rid of as much stuff in your OS and software stack as possible should be the security teams ultimate goal, so you have less to upgrade in the end. But actual security updates just come out at a tremendous rate, and you need a QA system that checks as much as it can before prod is upgraded.

I do agree with more frequent upgrades, but it has to be part of the culture. The longer you wait, the harder it gets. Unfortunately, I have worked in some heavily tech-debt-laden environments where upgrading anything required an act of god. I've logged on to production servers with 1500+ days of uptime at multiple companies. Nothing had been updated since well before that time. At one place, I recall encountering a…

in our case, updates were done on a staggered schedule, automatically, and rebooted at a particular agreed upon downtime window. dev, then test, then live machines. I had to explain multiple times to them, for example, that I have updated the system, but the reboot is scheduled for 3 days from now.
Post reply on HN