Live data from Hacker News

SQLite Critical CVEs or LLM Slop?

research.jfrog.com

261–270 of 406 posts

Re: SQLite Critical CVEs or LLM Slop?

#261
post #254

Earlier quoted context omitted.

Eh, I'm not going to litigate your claims. My point is it's silly to whine that HN is a place where multiple points of view on the topic are aired out and discussed. If you want a personal echo chamber where only your own beliefs are affirmed and anything else is flagged off or downvoted, I'm sure you can go find one or, worst case, vibe code one into existence.

Fair so let me be clear. I’m whining because the “next token predictor” reductionist point of view has been wrong and is only growing more wrong with time. Clearly these things can do things that actually matter. Do you disagree?

Even now you're engaging in this discussion as though I'm trying to litigate your point and that somehow forcing me to concede is, what, winning? I don't know.

I get the impression you want me to concede that the particular points of view you disagree with aren't worthy of representation here on HN.

I'm not going to do that.

Re: SQLite Critical CVEs or LLM Slop?

#262
post #52

We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are. LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are dealing with probabilities in a situation where certainties, not probabilities, matter, you’re going to get dinged on credi…

> We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are.

I see no credible corroboration. More likely its folks having no more care for what they are doing than the bots themselves.

> Now, we all pay the consequence, to the tune of hundreds of thousands if not millions of dollars of wasted productivity from teams that have to deal with the resulting fall-out of this usage of “AI”.

People said the same about email spam ... until they engaged spam filters. CVE report slop is simply spam. Complaints are better directed at the filters, not the filtered.

Re: SQLite Critical CVEs or LLM Slop?

#263
post #238
post #172

Earlier quoted context omitted.

Countless directors and managers are now cosplaying as engineers. I've seen so many myself and that's just my tiny slice of this engineering world

Engineers cosplay as physicists and mathematicians every day. What's your point? Think of it pragmatically. If they can do the job they can do the role.

> If they can do the job they can do the role.

Obviously.

Can they do the job? Because right now, government decisions are based on AI generated code, which was verified by nobody who can do that. So the cost of an unsatisfactory answer is quite high.

Re: SQLite Critical CVEs or LLM Slop?

#264
post #172

Earlier quoted context omitted.

Countless directors and managers are now cosplaying as engineers. I've seen so many myself and that's just my tiny slice of this engineering world

It is pretty funny to see the shoe on the other foot, since it's usually software engineers with unearned arrogance about other fields.

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…

Re: SQLite Critical CVEs or LLM Slop?

#265
post #69
post #3

This is going to be fun for organizations that are mandated to patch all CVEs, isn't it?

One can hope that will put pressure on the industry to design a better system than CVEs. The signal noise ratio was already terrible before LLMs, I cannot imagine that will still be a meaningful system in 10y. But I’m too cynical to not consider all the middlemen who benefit from the status quo

It's going to be very very difficult to build this system as the exploitability of any particular CVE can massively vary depending on your system configuration.

There are a lot of things that are bugs, but cannot be exploited in a standard configuration, most people would wonder why this is even a CVE.

But then you have those users that would have the application, then something like a report module that was imported, and another 3rd party module that imports images, and maybe another one that arranges the images in a chart. And suddenly that isolated CVE is now exploitable by user written data because of the original bug, it just required a complex and unexpected chain to get there.

Re: SQLite Critical CVEs or LLM Slop?

#267
post #52

We can chalk this up as another example of over-exhuberance by what folks believe LLMs can accomplish vs. what they actually are. LLM-based “AI” is able to use its vast corpus of inputs and calculate the most statistically likely output in a given situation. It is probabilistic, and when you are dealing with probabilities in a situation where certainties, not probabilities, matter, you’re going to get dinged on credi…

Wow you just got us a complete nostalgia moment to the good old times when the computer who always beats us at chess became `not artificial intelligence`...

Re: SQLite Critical CVEs or LLM Slop?

#268

Earlier quoted context omitted.

Why is the brain probabilistic instead of deterministic?

Probabilistic and deterministic are not opposites. The brain is deterministic at the level of specific interactions, which process inputs in a highly chaotic (but still deterministic) manner into probabilistic outcomes. The opposite of deterministic is random , i.e. in the quantum sense of truly no relationship between input and output. There are probably some quantum effects in the brain here and there, but the vast…

Ok right, but then I don't see the original point. Or like, you don't seem to be appealing to a hard science/soft science distinction here if the question revolves around what conceptual model is most "useful" to us. Useful for what? For predicting future actions? That makes sense, but does actually that speak to op's (possibly still fraught) metaphysical/semantic point here? It just feels like you are speaking over it, right? They could just as easily counter that a probabilistic model of the physical brain is not a very useful description of human intelligence, so why use it? You can't appeal to materialism here because you are already practicing some implied pragmatism in your commitments. You pretty much have as much ground to stand on as they do!

Re: SQLite Critical CVEs or LLM Slop?

#269
post #151

Earlier quoted context omitted.

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…

> but being able to generate probabilistic outputs based on inputs is not what makes us intelligent. ??? Of course it is. The brain is mechanically not capable of doing anything other than that. Do you believe the brain is something other than a bundle of probabilistic physical interactions? Or are brains not the source of what we call intelligence?

May I suggest the excellent & recent book: "The brain. In theory" by Romain Brette?

This is going to elevate your thinking on this no end, if you're interested.

Re: SQLite Critical CVEs or LLM Slop?

#270
post #42

Earlier quoted context omitted.

> - Firstly, you quickly realise how irrelevant CVSS scores are Even if you factor in the environmental score? I realize it's a lot more work, but it basically allows you to tune the score to get any value you want.

Imagine a YAML parsing library that can cause an out-of-memory exception if you give it a YAML file greater than 3 megabytes. If you're an online service where untrusted users can submit arbitrary YAML, and an out-of-memory exception is a severe problem, then it's severity 10. If you're an online service that doesn't use yaml in any way, but your web framework bundled the library as a transitive dependency because ya…

Exactly, the amount of time it takes to figure out if you're exploitable generally exceeds the time to patch the application in the majority of the cases. You tend to try to focus on the ones that will cause the most interruption.

And then you can have all kind of other fun things, like users don't upload YAML so you think you're safe, but a clever hacker figures out another minor parser error that makes your JSON seem like YAML and suddenly YAML.so has loaded and you're now parsing a document that shouldn't be possible.

Post reply on HN