4 ms·

> 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"

> 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, there is an incentive not to upgrade when things are working, because it takes effort to familiarize yourself with new features, decide what should be enabled and what should be disabled, etc. And while the Linux kernel takes compatibility seriously, most distros do not and introduce compatibility-breaking changes with regularity. Binary compatibility is non-existent. Source compatibility is a crapshoot. In contrast, you absolutely need to care about security bugs that allow people to run code on your system. So of course people want to treat security bugs differently from everything else and prioritize them.

IshKebab 6mo ago
Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.
- tptacek 6mo ago
  Everything has a poor security track record. That's the point.
  - akerl_ 6mo ago
    Well, except OpenBSD. They’ve only had two vulns in forever.
    - tptacek 6mo ago
      You mean "in the default install, in a heck of a long time". :)
    - cperciva 6mo ago
      Only two remote code execution vulnerabilities in the default configuration. But that's not the only type of security bug.
      - tptacek 6mo ago
        They're trolling me. :)
      - akerl_ 6mo ago
        As `tptacek caught on to, I was joking since OpenBSD's published claim is such a convenient comparison to the idea upthread that Linux specifically had a poor track record.
  - IshKebab 6mo ago
    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.
    - akerl_ 6mo ago
      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.
    - tptacek 6mo ago
      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?
      - IshKebab 6mo ago
        Then your point makes even less sense. Everything has security vulnerabilities therefore they are no different to other bug classes? What?
DarkNova6 6mo ago
And this is the best-case scenario. Because once updates become opt-out it simply becomes an attack vector of another type. If the updated code is not open source, you are trusting blindly that not some kind of different remote code execution just happened without you knowing it.
- franktankbank 6mo ago
  If you don't personally review every line then you are already trusting blindly.
  - hyperpape 6mo ago
    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 PyPi (though I believe that the most recent release of any random package on PyPi is still more likely safe than not--it's just a numbers game).
    - franktankbank 6mo ago
      I get what you are saying but as you said, if you are already under attack you can't trust your own computer, you just hope that you aren't downloading another exploit/bogus update. Real software I imagine is not so easy to pwn so completely but I don't know.
    - jcul 6mo ago
      Maybe just not the very latest. https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns https://blog.yossarian.net/2025/11/21/We-should-all-be-using...
rcxdude 6mo ago
I think part of it is that, especially at the kernel level, it can be hard to really categorise bugs into security or not-security (it has happened in the past that an exploit has used a bug that was not thought to be a security problem). There's good reason to want to avoid updates which add new features and such (because such changes can introduce more bugs), but linux has LTS releases which contain only bug fixes (regardless of security impact) for that situation, and in that case you can just stay up to date with very minimal risk of disruption.
miki123211 6mo ago
And if you're the kind of person who cares about that, you pay a vendor that gives you 10 years on the same distro version. Or just use an off-brand RHEL I guess.
the__alchemist 6mo ago
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? Why can someone on the internet write to this system?" Many times, there will be a system that's core purpose is to perform some numerical operations, display things in a UI, accept user input via buttons etc, and I'm thinking "This has a [mandatory? automatic? People are telling me I have to do this or my life will be negatively affected in some important way?] security update? There's a vulnerability?" I think: Someone really screwed up at a foundational requirements level!.
- warkdarrior 6mo ago
  > 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.
socalgal2 6mo ago
> 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. The point is that all of those bugs are now trivial to exploit and so will be exploited
Muromec 6mo ago
>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.
- keeganpoppen 6mo ago
  exactly. it is something you genuinely never need to think about, except for once in a blue moon. or, more like once in a leap year. and completely unmeasured by the "we will update it when our [horrific] business processes say it's okay" crowd is the cumulative angst of shit being broken FOR NO REASON. and that is to say nothing of the security vulnerabilities and all the other reasons that exist for updating your software.
  - SAI_Peregrinus 6mo ago
    The slower you update, & the longer you try to maintain a "long-term support" branch, the harder updates get. Gradual changes with a rolling release system are much, much simpler than the massive step changes of a "stable" distro.
keeganpoppen 6mo ago
but this simply isn't true. everyone thinks "oh well my use cases will never hit any of those bugs", but then there is one person in your org who hits that particular bug and it drives them batty. it is a retro-justification for doing things the wrong way "For the Right Reason". like... no one would be like "NEVER change the oil in your car unless the light goes off". we're not talking about Micro$oft here, where you literally have to pray to your deity of choice every time you click the update button. we are talking about the Linux kernel. i do not even need a thumb to count on one hand the amount of times a kernel update has significantly impacted my life. whereas probably 50% of my Windows updates break at least one of my peripherals, and OS X isn't exactly much better these days.

IshKebab 6mo ago

Yeah that attitude really makes no sense, and I don't see why AI finding security bugs would make people "finally understand". I suspect it's just an excuse for Linux's generally poor security track record.

tptacek 6mo ago
Everything has a poor security track record. That's the point.
- akerl_ 6mo ago
  Well, except OpenBSD. They’ve only had two vulns in forever.
  - tptacek 6mo ago
    You mean "in the default install, in a heck of a long time". :)
  - cperciva 6mo ago
    Only two remote code execution vulnerabilities in the default configuration. But that's not the only type of security bug.
    - tptacek 6mo ago
      They're trolling me. :)
    - akerl_ 6mo ago
      As `tptacek caught on to, I was joking since OpenBSD's published claim is such a convenient comparison to the idea upthread that Linux specifically had a poor track record.
- IshKebab 6mo ago
  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.
  - akerl_ 6mo ago
    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.
  - tptacek 6mo ago
    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?
    - IshKebab 6mo ago
      Then your point makes even less sense. Everything has security vulnerabilities therefore they are no different to other bug classes? What?

DarkNova6 6mo ago

And this is the best-case scenario. Because once updates become opt-out it simply becomes an attack vector of another type. If the updated code is not open source, you are trusting blindly that not some kind of different remote code execution just happened without you knowing it.

franktankbank 6mo ago
If you don't personally review every line then you are already trusting blindly.
- hyperpape 6mo ago
  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 PyPi (though I believe that the most recent release of any random package on PyPi is still more likely safe than not--it's just a numbers game).
  - franktankbank 6mo ago
    I get what you are saying but as you said, if you are already under attack you can't trust your own computer, you just hope that you aren't downloading another exploit/bogus update. Real software I imagine is not so easy to pwn so completely but I don't know.
  - jcul 6mo ago
    Maybe just not the very latest. https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns https://blog.yossarian.net/2025/11/21/We-should-all-be-using...

rcxdude 6mo ago

I think part of it is that, especially at the kernel level, it can be hard to really categorise bugs into security or not-security (it has happened in the past that an exploit has used a bug that was not thought to be a security problem). There's good reason to want to avoid updates which add new features and such (because such changes can introduce more bugs), but linux has LTS releases which contain only bug fixes (regardless of security impact) for that situation, and in that case you can just stay up to date with very minimal risk of disruption.

miki123211 6mo ago

And if you're the kind of person who cares about that, you pay a vendor that gives you 10 years on the same distro version. Or just use an off-brand RHEL I guess.

the__alchemist 6mo ago

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? Why can someone on the internet write to this system?" Many times, there will be a system that's core purpose is to perform some numerical operations, display things in a UI, accept user input via buttons etc, and I'm thinking "This has a [mandatory? automatic? People are telling me I have to do this or my life will be negatively affected in some important way?] security update? There's a vulnerability?" I think: Someone really screwed up at a foundational requirements level!.

warkdarrior 6mo ago
> 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.

socalgal2 6mo ago

> 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. The point is that all of those bugs are now trivial to exploit and so will be exploited

Muromec 6mo ago

>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.

keeganpoppen 6mo ago
exactly. it is something you genuinely never need to think about, except for once in a blue moon. or, more like once in a leap year. and completely unmeasured by the "we will update it when our [horrific] business processes say it's okay" crowd is the cumulative angst of shit being broken FOR NO REASON. and that is to say nothing of the security vulnerabilities and all the other reasons that exist for updating your software.
- SAI_Peregrinus 6mo ago
  The slower you update, & the longer you try to maintain a "long-term support" branch, the harder updates get. Gradual changes with a rolling release system are much, much simpler than the massive step changes of a "stable" distro.

keeganpoppen 6mo ago

but this simply isn't true. everyone thinks "oh well my use cases will never hit any of those bugs", but then there is one person in your org who hits that particular bug and it drives them batty. it is a retro-justification for doing things the wrong way "For the Right Reason". like... no one would be like "NEVER change the oil in your car unless the light goes off". we're not talking about Micro$oft here, where you literally have to pray to your deity of choice every time you click the update button. we are talking about the Linux kernel. i do not even need a thumb to count on one hand the amount of times a kernel update has significantly impacted my life. whereas probably 50% of my Windows updates break at least one of my peripherals, and OS X isn't exactly much better these days.