Seeing some bad takes about the memcached mess, such as this one: https://isc.sans.edu/forums/diary/How+did+this+Memcache+thing+happen
No ordinary end user is looking at pages on memcached's github or googling stackoverflow answers about it.
They do pkg-thing-install memcached && systemd-turn-on memcached, and then they uncomment one line in their mediawiki config and tada, it just works.
At no point are they going to be warned that they've unleashed an eldritch ddos horror onto the internet.
Software needs good defaults.
@cb system package management also needs to be up to date. All too often do I have to install this-that-or-other and find that it's at least 2-3 revisions behind (on a stable install) Maybe if I chose a testing/bleeding edge version I could get 1-2 major versions behind.
When these big bad Linux distributions claim "crap ton # of packages supported", it adds to the probability that you won't get anything up to date and possibly insecure versions.
@mulander @cynicalsecurity @cb I think that made the problem worse, rather than creating the problem. Oftentimes folks assume that if you are deploying something, you know about it, and "obviously" will take the proper steps. But that's not how it works.
Even those of us it is obvious to don't *like* having to fix things that deploy broken or dangerous by default.
One program I was writing wrote data to files and his point was always "do not corrupt the data while failing". He hammered my code until I finally understood that, on failure, I had to absolutely protect the data files hence learn about catching signals in C and cleaning up never leaving anything "dirty".
@cb I think a related issue is that for (some) developers it is still hard to understand that users see your software very differently and use it to solve their problem, i.e. it’s a means to an end.
It brings along many inherent assumptions which can act like blind spots.