3 ms·

This is a misleading title. The official stance from their document they’re quoting is: - older operating systems receive security patches - not all security

by dagmx 4y ago

This is a misleading title. The official stance from their document they’re quoting is: - older operating systems receive security patches - not all security fixes (note: not a patch) can apply to older operating systems because some depend on architectural changes. This is the norm. You don’t want major architectural changes being back propagated to older OS versions. That’s a sys admin nightmare where a security update now breaks all your drivers because Apple would have had to port DriverKit backwards and restricted kexts. All these sites are reporting it as some kind of failing but it’s just sensationalism.

webmobdev 4y ago
Making architectural changes to create a patch implies that they only prefer to work on the latest codebase. What you are describing is a lack of commitment to long-term-support for older OS (in effect, planned obsolescence); so the head line is indeed accurate. Apple providing only partial support for older OSes can be quite meaningless depending on the security hole they decide to not fix "because it is too much work".
- dagmx 4y ago
  Your comment belies that you have never worked on kernel and system level infrastructure with mass deployment. You can't just patch an old kernel for all security flaws because you may break other things like how third party drivers interact with the kernel. That interaction itself may be the cause of a security flaw (and in fact is, which is why they're moving to user space kernels with DriverKit) How would you posit that you patch an architectural security hole that would break users setups if you were to backport it?
  - webmobdev 4y ago
    You don't backport - you create a separate hacky patch for the older codebase that temporarily fixes the issue. (In fact, that's exactly what everyone does when a serious bug is found in a current version software that they know requires an architectural change for a long term fix). Ensuring compatibility without breaking stuffs (like Windows was once famous for) or long-term support for softwares is not a new concept. What you pointed out in your comments is how Apple prioritises its resource - it's perfectly reasonable to focus only on the latest version of codebase as that is obviously easier, and Apple's business model is built on that. That's the mindset / policy that certainly gives you the luxury to think in terms of changing the architecture to fix a bug the "right" way but at the expense of ignoring older codebases.
    - dagmx 4y ago
      You completely ignored my very salient and real example of where “separate hacky patches” can’t work.
Liquid_Fire 4y ago
Doesn't this still mean that some security issues may go unpatched in older OS versions? I wouldn't expect them to backport major architectural changes, but they would need to fix the security issue in some other way, otherwise malware will exploit it.
- dagmx 4y ago
  In my comment: > not all security fixes (note: not a patch) can apply to older operating systems because some depend on architectural changes. Per your second point, how would you go about preventing a kext from wreaking havoc in an older OS without changing the fundamental nature of kernel interaction that would only apply to a newer OS? Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. e.g if you break my ability to use kexts on an older OS, but third party hardware I depend on still requires a kext, which is worse? A low risk of malware, or not being able to do my job at all?
  - Liquid_Fire 4y ago
    > Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. Of course. I wouldn't expect them to backport fixes for things that were considered outside the scope of security protections in the original version. But I also expect cases like this to be uncommon, because how many things can you completely rearchitect each version? The article also says: > Joshua Long has tracked the CVEs patched by different macOS and iOS updates for years and generally found that bugs patched in the newest OS versions can go months before being patched in older (but still ostensibly “supported”) versions, when they’re patched at all. Focusing just on the issues that do actually get patched (if we assume the ones that don't fall into the category you describe), if they are getting fixed months later this still leaves these "supported" systems vulnerable for months.
    - dagmx 4y ago
      With recent OS versions they’ve actually been rearchitecting a lot, all the way from the kernel to user space frameworks to enable those changes and down to things like their bootloaders. See DriverKit and ExtensionKit for some examples but there’s been several analysis of the OS updates each year. I assume that’ll settle with time because you’re right that it’s not something that should be often. However that only applies to single code paths. The OS upgrades different things each year so it becomes frequent if you account for everything. As for delays for older systems, that is unfortunate. It’s likely just a resourcing issue with all hands trying to get the newest OS to be stable since the goal is to keep users moving forward to architecturally more modern OS versions . The security patches for older systems are therefore a crutch till they can get those users onto the newer OS.
deleted 4y ago
[deleted]

by dagmx 4y ago

webmobdev 4y ago

Making architectural changes to create a patch implies that they only prefer to work on the latest codebase. What you are describing is a lack of commitment to long-term-support for older OS (in effect, planned obsolescence); so the head line is indeed accurate. Apple providing only partial support for older OSes can be quite meaningless depending on the security hole they decide to not fix "because it is too much work".

dagmx 4y ago
Your comment belies that you have never worked on kernel and system level infrastructure with mass deployment. You can't just patch an old kernel for all security flaws because you may break other things like how third party drivers interact with the kernel. That interaction itself may be the cause of a security flaw (and in fact is, which is why they're moving to user space kernels with DriverKit) How would you posit that you patch an architectural security hole that would break users setups if you were to backport it?
- webmobdev 4y ago
  You don't backport - you create a separate hacky patch for the older codebase that temporarily fixes the issue. (In fact, that's exactly what everyone does when a serious bug is found in a current version software that they know requires an architectural change for a long term fix). Ensuring compatibility without breaking stuffs (like Windows was once famous for) or long-term support for softwares is not a new concept. What you pointed out in your comments is how Apple prioritises its resource - it's perfectly reasonable to focus only on the latest version of codebase as that is obviously easier, and Apple's business model is built on that. That's the mindset / policy that certainly gives you the luxury to think in terms of changing the architecture to fix a bug the "right" way but at the expense of ignoring older codebases.
  - dagmx 4y ago
    You completely ignored my very salient and real example of where “separate hacky patches” can’t work.

Liquid_Fire 4y ago

Doesn't this still mean that some security issues may go unpatched in older OS versions? I wouldn't expect them to backport major architectural changes, but they would need to fix the security issue in some other way, otherwise malware will exploit it.

dagmx 4y ago
In my comment: > not all security fixes (note: not a patch) can apply to older operating systems because some depend on architectural changes. Per your second point, how would you go about preventing a kext from wreaking havoc in an older OS without changing the fundamental nature of kernel interaction that would only apply to a newer OS? Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. e.g if you break my ability to use kexts on an older OS, but third party hardware I depend on still requires a kext, which is worse? A low risk of malware, or not being able to do my job at all?
- Liquid_Fire 4y ago
  > Not everything is backwards patchable. Some things are results of decades long development practices that patching would cause the OS to break for users who aren't able to upgrade yet. Of course. I wouldn't expect them to backport fixes for things that were considered outside the scope of security protections in the original version. But I also expect cases like this to be uncommon, because how many things can you completely rearchitect each version? The article also says: > Joshua Long has tracked the CVEs patched by different macOS and iOS updates for years and generally found that bugs patched in the newest OS versions can go months before being patched in older (but still ostensibly “supported”) versions, when they’re patched at all. Focusing just on the issues that do actually get patched (if we assume the ones that don't fall into the category you describe), if they are getting fixed months later this still leaves these "supported" systems vulnerable for months.
  - dagmx 4y ago
    With recent OS versions they’ve actually been rearchitecting a lot, all the way from the kernel to user space frameworks to enable those changes and down to things like their bootloaders. See DriverKit and ExtensionKit for some examples but there’s been several analysis of the OS updates each year. I assume that’ll settle with time because you’re right that it’s not something that should be often. However that only applies to single code paths. The OS upgrades different things each year so it becomes frequent if you account for everything. As for delays for older systems, that is unfortunate. It’s likely just a resourcing issue with all hands trying to get the newest OS to be stable since the goal is to keep users moving forward to architecturally more modern OS versions . The security patches for older systems are therefore a crutch till they can get those users onto the newer OS.

deleted 4y ago

[deleted]