Not really, I depend on my distro to push updated packages that I will update. And I also hope that my distro pushes me binary diffs so that it's going to be very fast.
The point is: in the context of a Linux distro, it's not true that you need dynamic linking to be able to do security patches effectively. What users do is to run the package manager to update the system; the package manager can provide updates to static binaries as well (and do it efficiently). It's just a matter of tooling; current package managers are designed around the concept of dynamic libraries, but they could be updated.
Generally, distros supply security updates. For example, Debian picks a version for a release and makes sure it has security updates for the entire release. Sometimes this requires backporting patches because the version is no longer supported upstream. This means an app can be shipped that will work for the life of the release without changes, while staying secure.
How do they do things like security updates (e.g. OpenSSL)?
I mean, if the system is immutable, do I have to download an install a completely new image? How often do such updates arrive?
And what does immutable even mean in practice? Do I have to start from a CD image or some special boot mode every time I want to install system updates?
Agreed, though updating your system shouldn't break other packages. If those other packages are a security risk then they too should be updated. Once done, garbage collect that which is not used.
There has always been a rule for bug-fix and security updates:
Apply the minimum necessary change to solve the problem.
This means cherry-picking the mainline patches where possible, or back-porting them where modification is required for them to apply (and work as intended) on older releases.
Especially with older versions it often isn't possible to update to a later upstream release because that depends on later versions of other packages. The dependencies can rapidly multiply to affect tens or even hundreds of packages.
Ubuntu patches were prepared and released within 4 hours of the security team being aware of the vulnerability. Same goes for Debian.
There are no problems with updates anymore. You don't have to download everything to update a bunch of static binaries. There are things, like bsdiff, that allow you to download and patch only tiny differences related to a security flaw.
There is no need for dynamic linking for updates. Really.
The simplest is to only use packages from a distribution like Debian and run unattended-upgrades or equivalent for the security-updates repository. They usually fix vulnerabilities in less than a day.
I include “security patch” in “behavior”, subject to both conditions above.
If B isn’t otherwise updated at a similar time, then yes, I advocate dependency update-only releases. I think this is as it should be. A project should be able to know what code it runs, specifically.
And yes, if a project is abandoned then security patches don’t get magically applied. Again, as it should be. The fact that you have an unmaintained dependency is itself a problem. You can’t just auto-apply security patches and expect things to keep working, ask any Linux distro. What needs to happen is a fork (or dropping the dependency). Tools warning you encourages this; silently auto-applying patches encourages everybody to separately do their own fixes and workarounds.
This has always been true, and also true for those that stick to LTS. If you want to receive security patches, you need to update your JDK. BTW, as the new deployment approach is to create a custom minimal runtime and bundle it with your app, your application may not need security patches, depending on what it does.
It’s good security practice, especially for anything internet facing.
Sure, you don’t have to do it obsessively, but if you let it stagnate you can have trouble updating things when critical vulnerabilities are found, and you have a huge job because multiple APIs have changed along the way.
Of course if they need to be manually updated, there's a strong likelihood that they are using vastly outdated versions of their dependencies. Users could be wide open to unpatched exploits.
Generally, all packages depending on that library will need to be rebuilt. But that is automatic when you do an update, it just may take time (either for packages to be rebuild locally, or by the build farm if you're using channels).
But you can manually do a hack to substitute a patched version when you want the fix right now: https://nixos.org/wiki/Security_Updates
There's an argument there - do you want to be at your distro's security update mercy, or have to remember/have two separate sets of security patch processes to run through?
Absolutely not. If you neglect keeping your packages up to date, it tends to get exponentially harder to upgrade them when you do need that critical bugfix.
No to both. The Linux distribution you use is responsible for backporting patches, fixing the vulnerability, building updated packages, testing them and sending the updates.
You get targeted security updates without changes in any other functionality.
Sorry for the noob question, but how do you ensure a Debian installation is always updated with the latest security patches? Do you just run `apt-get upgrade` everyday? Isn't there a risk of breaking things?
Many of the thousands of dependencies in a given distro could file a new vulnerability overnight. Your immutable distro will need updating pronto.
reply