4 ms·
Its not about the size of the packages, its about managing an entire system, for whatever definition of the word "system" In the "olden" days, you would patch
by spion 6y ago
Its not about the size of the packages, its about managing an entire system, for whatever definition of the word "system"
In the "olden" days, you would patch the vulnerable dependency and be sure that all services running on the machine have been updated to the new version. (in theory - if everything works great and there is ABI compatibility etc etc).
Since the library is installed in a well-known system location, there are only a few paths in the filesystem that you would need to check to make sure it's up to date. This makes machine maintenance easier.
Nowadays, to patch a vulnerable dependency you need to potentially go to all individual projects, check whether they depend on it, update the version for that project, make sure to rebuild any containers that... contain it. Rinse, repeat.
There is also not a single place where the dependencies live, so you can't just run the same command across multiple machines to do the check - you have to check the directory structure of every individual service.
This can be very slow and painful.
- pas 6y agoAgreed. Yet it seems the ecosystem simply accepts this trade-off. For increased productivity, increased memory-management security, etc.