4 ms·
Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated. For a system tha
by kbenson 5y ago
Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated.
For a system that widely uses dynamic libs, that's fairly easy to do. Check the version of the installed library, along with any patches it might have, and you have a good idea of whether it needs to be updated.
Now, imagine there's a zlib exploit. That's a lot of things in the system that need to be updated. It's so ubiquitous that even in a system that's almost entirely built with dynamic libs, there are a few that use it as a static lib, and you'll have to make sure those are updated too (go look at the last zlib CVE and the major distro updates to it and you'll see all those packages, sometimes a couple days later as they discover them too).
A world where these are all statically compiled (or bundled separately in containers) is much more complex. It's not impossible, but you don't naturally get some of the work done for you. To some degree we're already going this way with containers though.
- Zababa 5y ago> Part of the problem is not just getting all the different applications and libraries up to date, but knowing which of them need to be updated. In which was? Is it because it's hard to know which version of zlib was used in X application, or is it because there is no centralized information about this? Maybe that's an opportunity right there: build a graph of dependencies of a system, and alert when something has been compromized and which are the consequences.
- xg15 5y ago> build a graph of dependencies of a system You mean in the sense that every application that comes with statically linked libraries should also come with some metadata indicating which libraries/versions are in there? This would work, but then you have the problem metadata always has: It can get out of sync with the actual thing, developers can forget to properly maintain it (or even to provide it at all) etc etc.
- Zababa 5y agoYou're right, I didn't answer the question of "who should maintain that stuff?". I was imagining something like libraries in JS or Rust, where people pin the dependencies of their libraries, so with this, you can build a graph of dependencies. I guess I have a very "github" centric vision of things and that most software isn't built this way, which would complicate things.
- kbenson 5y agoTo some degree most distro's have this graph and it's somewhat queryable (rpm has to agilities for this, if not easily consumed). The difference is in how accurate and queryable it is, and how easy it is to be fairly sure everything is up to date. It's not a show stopping problem, but it is something that should be considered and thought closely about. This is a security adjacent problem, and changes in it can have consequences that are larger than "I'm running a library that doesn't have the feature I want".