3 ms·

> It will miss private dynamic libraries, Docker containers, potentially virtual envs. Yes, it will. Does that make dynamic libraries a red herring, or does it

> It will miss private dynamic libraries, Docker containers, potentially virtual envs. Yes, it will. Does that make dynamic libraries a red herring, or does it mean these approaches all make the same mistake? Please think before you answer. Just because something's common doesn't mean it's wise or necessary. > it has a huge cost in terms of maintenance and backwards compatibility How much are those "huge costs" unique to that approach? Maintenance and backwards compatibility are still problems even with static linking or embedding into containers or any other alternative. It's disingenuous to count common problems against only one approach. The real tradeoff is between problems that are unique to each, and it's possible to disagree about which choice is best without stacking the deck for one side.

nicoburns 3y ago
Ultimately if the app is unmaintained, then it's likely to have security issues even if it's using dynamic libraries. If it is maintained then it shouldn't be a big deal to update it.
- deleted 3y ago
  [deleted]
- layer8 3y ago
  Security is not black and white. Better to be able to fix some security issues of an unmaintained app than none. This is a bit of a tangent, but I don’t think it is sustainable in the long run to require the ever-growing volume of software in use to all be actively maintained. We should find a model of software development where we can achieve sufficient security without having to maintain and rebuild the world all the time.
  - nicoburns 3y ago
    Long term I think we'll get most of the way there by eliminating C and C++ from our software stacks. Most security vulnerabilities (and even more of the most serious ones) are memory safety or UB related. And systematically eliminating those will give us more time to audit our code for other issues. Eliminating C and C++ also likely leads us to standardised build systems which makes rebuilding things much much easier.

nicoburns 3y ago

Ultimately if the app is unmaintained, then it's likely to have security issues even if it's using dynamic libraries. If it is maintained then it shouldn't be a big deal to update it.

deleted 3y ago
[deleted]
layer8 3y ago
Security is not black and white. Better to be able to fix some security issues of an unmaintained app than none. This is a bit of a tangent, but I don’t think it is sustainable in the long run to require the ever-growing volume of software in use to all be actively maintained. We should find a model of software development where we can achieve sufficient security without having to maintain and rebuild the world all the time.
- nicoburns 3y ago
  Long term I think we'll get most of the way there by eliminating C and C++ from our software stacks. Most security vulnerabilities (and even more of the most serious ones) are memory safety or UB related. And systematically eliminating those will give us more time to audit our code for other issues. Eliminating C and C++ also likely leads us to standardised build systems which makes rebuilding things much much easier.