4 ms·

This is what happens as things move more into mainstream from a few technical users using this as intended in sort of a small walled garden so to speak and then

by quags 5y ago

This is what happens as things move more into mainstream from a few technical users using this as intended in sort of a small walled garden so to speak and then as it grows you get non technical users and bad actors. Look how smtp started, open for anyone where open relays were expected, to what we have today - still a large spam problem, compromised accounts with security on top of it. There are lots of rewrites and different smtp programs as things like smail and sendmail were replaced by exim, postfix and qmail (qmail which is free software, but really unmaintained and could be anyone's problem if they wanted). I'd argue if there is an application that being built on libraries with out a full understanding of keeping them maintained over the years you will get a massive cluster fuck with code rot. These are things that are learned with experience, as a dev starts they take short cuts and learn from the mistakes. It is not a bad system when you are learning from your mistakes. There are simple solutions like using an operating system that is maintained. Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system.

xg15 5y ago
Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons. > Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system. But how does an updated OS help if the packages themselves are not updated?
- danaris 5y ago
  > Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons. I very much hope not. I would greatly prefer to see some certification bodies arise that can vet libraries for exploits like this and give a certificate of some sort saying "This library is safe to use". Of course, that requires them to have some extremely good exploit-finders.
- throw0101a 5y ago
  > But how does an updated OS help if the packages themselves are not updated? Package maintainers apply patches and roll a new package version (e.g., +deb11u1). At some point the package maintainers themselves may not want to babysit things anymore and deprecate the package. But most packaging systems that I'm aware of have mechanisms for applying patches. In many cases even if the software itself is still maintained, the package maintainers may only apply a specific patch to ensure maximum compatibility. It's why many of us prefer 'slow moving' distros with "old" packages: minimal change for a given version and then only when 'necessary'.

by quags 5y ago

xg15 5y ago

Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons. > Log4j and java packages exist for example in operating systems that get security updates - and continue to do so for the life of the operating system. But how does an updated OS help if the packages themselves are not updated?

danaris 5y ago
> Yeah, my guess is also that long-term, software development will involve less libraries and more "reinventing the wheel" for those reasons. I very much hope not. I would greatly prefer to see some certification bodies arise that can vet libraries for exploits like this and give a certificate of some sort saying "This library is safe to use". Of course, that requires them to have some extremely good exploit-finders.
throw0101a 5y ago
> But how does an updated OS help if the packages themselves are not updated? Package maintainers apply patches and roll a new package version (e.g., +deb11u1). At some point the package maintainers themselves may not want to babysit things anymore and deprecate the package. But most packaging systems that I'm aware of have mechanisms for applying patches. In many cases even if the software itself is still maintained, the package maintainers may only apply a specific patch to ensure maximum compatibility. It's why many of us prefer 'slow moving' distros with "old" packages: minimal change for a given version and then only when 'necessary'.