cb is a user on bsd.network. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
cb @cb

Seeing some bad takes about the memcached mess, such as this one: isc.sans.edu/forums/diary/How+

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.

· Web · 13 · 17

@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.

@cb This "Software needs good defaults." is probably the single most important issue affecting software world-wide.

The name we used for it back in the 70s was "failsafe" as opposed to "fail deadly" but it has long been forgotten.

@cynicalsecurity @cb I think that process started in the early 2000s when Linux and others transitioned more to the OpenBSD model of not having everything turned on out of the box. But, that is really as far as they got. "Don't have everything installed and turned on. Got it."

@kurtm @cynicalsecurity @cb I think i started around 2007 with 'low development friction' things like with rails 'make a blog in 15 minutes' and everything streamlined to zero configuration *for development*. They didn't however realize that development defaults land in production.

@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.

@kurtm @mulander @cb well… my father used to "test" my code and, as his job was partially competition analysis, he had a pretty solid view of "fail safe".

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 am totally with you on the secure by default setting! Have a reasonable default and have the user to actively change it.

As a security dude for a large hoster I am now seeing the havoc the combination of dumb defaults and irresponsible customers cause.

@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.