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

Significant raise of reports

lwn.net

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Significant raise of reports

#141

Post by akerl_ »

IshKebab wrote: post #138
tptacek wrote: post #91

Earlier quoted context omitted.

Everything has a poor security track record. That's the point.

1. That's bollocks. Obvious bullshit. All software doesn't have the same security track record. Do you also think sendmail and seL4 have an equally poor security track record? 2. Even if everything did have an equally poor security track record, why would that mean security bugs are no more significant than any other bug? Honestly I'm dubious you've thought about this at all.

Without even wading into trying to rank projects by track record, it's worth noting that "Everything has a poor security track record" and "All software doesn't have the same security track record" are not contradictory statements.

Re: Significant raise of reports

#142

Post by tptacek »

IshKebab wrote: post #138
tptacek wrote: post #91

Earlier quoted context omitted.

Everything has a poor security track record. That's the point.

1. That's bollocks. Obvious bullshit. All software doesn't have the same security track record. Do you also think sendmail and seL4 have an equally poor security track record? 2. Even if everything did have an equally poor security track record, why would that mean security bugs are no more significant than any other bug? Honestly I'm dubious you've thought about this at all.

I didn't say "all software has the same security track record". seL4 has a much better track record than Sendmail by dint of not doing very much. I'm pretty comfortable with what people do and don't think about how much thinking I've done on this topic. Done much work with L4?

Re: Significant raise of reports

#143

Post by Muromec »

chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

>it takes effort to familiarize yourself with new features, decide what should be enabled and what should be disabled, etc.

What features? I update my rolling release once a month and nothing changes for the last 10 ish years. Maybe pipewire/pulse thingy was annoying and bluetooth acted a bit. With docker on rpi I even upgrade the whole zoo of things by just rebooting.

Re: Significant raise of reports

#144

Post by jcul »

hyperpape wrote: post #86
franktankbank wrote: post #82

Earlier quoted context omitted.

If you don't personally review every line then you are already trusting blindly.

As blind as my belief that Asia exists, because I haven't personally navigated there. Hell, I've used electricity (using it right now), but I couldn't do the experiments you need to do to get myself to an 1850s level of understanding of how it works, much less our current level. I trust that Linux has a process. I do not believe it is perfect. But it gives me a better assurance than downloading random packages from P…

Maybe just not the very latest.

https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

Re: Significant raise of reports

#145

Post by array_key_first »

glimshe wrote: post #4

The last paragraph is interesting: "Overall I think we're going to see a much higher quality of software, ironically around the same level than before 2000 when the net became usable by everyone to download fixes. When the software had to be pressed to CDs or written to millions of floppies, it had to survive an amazing quantity of tests that are mostly neglected nowadays since updates are easy to distribute." Was so…

I don't think it was better, but it was generally less buggy or higher quality for sure. And I think it's both because of testing and because of lower complexity.

For example, desktop apps are actually much less complex than web based applications. It doesn't really seem that way, but web apps are distributed, with a client and server on separate machines. That, to me, introduces a whoooole new layer of error conditions and flakiness.

Also, QA has been largely cast aside. Nobody is really doing manual click-around type testing, and nobody is writing user guides anymore.

Re: Significant raise of reports

#146

Post by warkdarrior »

the__alchemist wrote: post #95
chromacity wrote: post #70

> people will finally understand that security bugs are bugs, and that the only sane way to stay safe is to periodically update, without focusing on "CVE-xxx" Linux devs keep making that point, but I really don't understand why they expect the world to embrace that thinking. You don't need to care about the vast majority of software defects in Linux, save for the once-in-a-decade filesystem corruption bug. In fact, t…

Details are important, but my mental model has settled as: Security bugs are being use in a manner to how politicians use think of the children . It's used as an auto-win button. There are things to me that compete with them in priorities. (Performance, functionality, friction, convenience, compatibility etc); it's one thing to weigh. In some cases, I am asking: "Why is this program or functionality an attack surface…

> In some cases, I am asking: "Why is this program or functionality an attack surface? Why can someone on the internet write to this system?"

With the help of LLMs, every software not in a vault has an attack surface. LLMs are quite good at finding different, non-obvious paths, and you can easily test their exploit candidates.

Re: Significant raise of reports

#147

Post by jasomill »

SoftTalker wrote: post #131
radlad wrote: post #116

Earlier quoted context omitted.

Yes but I would push back a little on the idea that you simply put yourself in a "mindset of writing bug-free code." Simpler code has fewer bugs. Embedded code tends to be simpler and more targeted in its role. Of course, putting yourself in the mindset of writing simpler code is great too - if you have the time to do so, and the problem you are solving is itself sufficiently simple.

Embedded code is also simpler because it has to be. When you are confined to a microcontroller, there isn't room for bloated app frameworks, hundreds of NPM packages, etc.

Depends on whether there's room in the budget to integrate something like a full-fat Raspberry Pi board, at which point, your light switches and thermostats can be full-fledged Kubernetes nodes if you like.

Never underestimate software developers' ability to simultaneously over- and underengineer a solution, especially if the only limitation is hardware cost (read: somebody else's problem).

Re: Significant raise of reports

#148

Post by array_key_first »

zozbot234 wrote: post #58
bastawhiz wrote: post #48

Earlier quoted context omitted.

You can't just write Rust in a part of the codebase that's all C/C++. Tools for checking the newly written C/C++ code for issues will still be valuable for a very long time.

You actually can? A Rust-written function that exports a C ABI and calls C ABI functions interops just fine with C. Of course that's all unsafe (unless you're doing pure value-based programming and not calling any foreign code), so you don't get much of a safety gain at the single-function level.

C ABI is not C++ ABI. People often write C/C++ but they're completely different languages. C++ is much higher level and modern. C++ is closer to Rust than it is to C.

Re: Significant raise of reports

#149

Post by bastawhiz »

zozbot234 wrote: post #58
bastawhiz wrote: post #48

Earlier quoted context omitted.

You can't just write Rust in a part of the codebase that's all C/C++. Tools for checking the newly written C/C++ code for issues will still be valuable for a very long time.

You actually can? A Rust-written function that exports a C ABI and calls C ABI functions interops just fine with C. Of course that's all unsafe (unless you're doing pure value-based programming and not calling any foreign code), so you don't get much of a safety gain at the single-function level.

If you're going to swap out one function in a chain of functions for a Rust version, you're destroying your codebase. You simply can't replace one tiny piece of code in a large codebase with a version in a different language. Doing so would be insane.

Re: Significant raise of reports

#150

Post by jcalvinowens »

> I suspect that bugs are reported faster than they are written, so we could in fact be purging a long backlog (and I hope so).

It's hard for me to imagine how this wouldn't be true. This isn't the "new normal", everyone is just running it into the ground and wringing every drop they can out of it right now.

It would be interesting to "backtest" how much higher the rate of vulnerability discovery would have been if all these new vulnerabilities were discovered in near real time as they were created, since that would be more predictive of the "new normal", in my opinion. I suspect it's not very significant: we're flushing a 20+ year backlog, and generally the rate at which vulnerabilities are created is lower today.

Post reply on HN