That's also why I am actively moving a fundamental and important internal service we have to just use python dependencies packaged in Debian stable packages. Sure, it may be a year or two behind in features, I may loose a nice debugging tool or two, but it is a very stable footprint, has security updates, breaks rarely. For ops-internal scripting and tooling, it's good.

I know this from a few friends who are deep into tabletop and boardgames, and they would regularly work with the one or two small stores around to get some special, expensive item (to help keep the shop afloat).

It is illegal, and in my book also immoral to deny such a candidate, but the other side of the coin is there.

A fairly unintuitive resolution to this is to setup a "fun and nonsense" budget and force yourself to spend it every half year, or to make a conscious plan on how to spend it over the year. If you plan the budget right, it won't hurt you, but it will force you to make your life better.

Maintenance, especially of owned property, seems similar to me. You should be saving up for the real "oh shit" situations, and you should accumulate a budget to just do things continuously. 6 months of routine maintenance budget saved up, what do we spend it on actively, before it becomes a mess?

Let's hope that reference is not too obscure...

We're most likely entering a year or two or rapid vulnerability discovery, patching, as well as reducing and minimalizing system footprints just to survive the onslaught of strange vulnerabilities from e.g. ancient and widely unused kernel modules.

If I was to nitpick, "melted" is kind of inaccurate and not entirely natural in this context. Technically, molten sand is also melted sand, because that's how you get it to that state? Usually, you'd hear about solidified magma, crystalized sand, cast iron, air-cast steel, unevenly settled corium... to make a better point on how it turned back into a solid and what to expect from it - something like "The molten sand crystalized into an unusual structure" would be clearer.

I'd usually rather hear "melted" if it is important to note that this had a phase change and back. Plastic on an electrical device may look melted, indicating heat. A hardened steel part may look melted, which may damage the hardening. Rubber on a hydraulic line may look melted, also indicating heat. A plastic container looking melted in the context of chemicals may indicate some compromise.

Now the words sound weird in my head. Thank you.

It is a huge security risk to treat systems as ancient eggshells you must not touch ever. A certain amount of touching has to be reasonable, because that is what foreign actors will do if they need to cause trouble. Apparently you could cause this company major operational harm with a pi zero. Why is that protected by professional ruin and jail time?

And I do think that security research should have some regulation about it, but it should be more about responsible handling of the privileged access you gained, or a responsibility to disclose found vulnerabilities in private and/or to a government entity. You know, "If you have gained access to a system, and you saw a button and you pressed it, you are on the hook for the damages". That is common practice with paid pentesters already.

But we're at a point where a court had do decide if discovering an endpoint on an API without authorization is a "circumvention of a security boundary" or not. Luckily, we now have a ruling that accessing API endpoints without authorization logic is no circumvention of a security boundary, due to a lack of a security boundary like authorization.

That's the level we are at. I don't want to know what happens if foreign nation state actors start acting on this seriously.

This is what I was thinking - I'd say the biggest step up a developer can make is to recognize that sometimes you need a bit of one approach, sometimes a bit of another one.

Sometimes minimalism is the way, and you need to wonder if the pain, workload or lacking capabilities and features are problematic. Or, sometimes adding the smallest possible thing is a good way, as long as we don't paint ourself into a corner and enable learning and accumulating information of what we actually need.

Sometimes buying a thing is a good way, if you can find a good vendor and a tool fitting your use case and especially if the effort of doing it on your own is high. This commonly occurs in security, because keeping up to date with the ongoing vulnerability and threat landscape can be a full job on its own.

And sometimes adding something bigger is the way, if the effort of maintaining it are less than the effort and pain incurred by not having it. Or if we can ramp up the effort of the thing incrementally, while reaping benefits along the way. This can be validated often by doing a small thing.

What the AI will do in my opinion is to push the bar more in this direction. Cozily hacking CRUD-Code in a web server together most likely won't be enough in a year or two for the average development job.

The CVEs here have their fair share of silly C problems, but also more rigid input validation and handling. These more rigid validations exclude stuff which may even be valid by the spec, but entirely problematic in practice.

As examples, take a look how many valid XML documents are practically considered unsafe and not parsed, for example due to recursive entity expansion. This renders the parsers not flawless and in fact not in spec.

Or, my favorite bait - there should be a maximum length limit on passwords. Why would you ever need a kilobyte sized password?

    memmove(args->begin_argv + extend,
            args->begin_argv + consume,
            args->endp - args->begin_argv + consume);   // ← bug

    retained_tail_begin = args->begin_argv + consume
    memmove(args->begin_argv + extend,
            retained_tail_begin,
            args->endp - retained_tail_begin);

    space_to_replace_end = args->begin_argv + extend
    retained_tail_begin = args->begin_argv + consume
    memmove(space_to_replace_end,
            retained_tail_begin,
            args->endp - retained_tail_begin);

And sorry, but I am ... frustrated by this. Why do my Debian 11 servers (currently upgrading, yes) have support for phone infrastructure from the 90s (ATM), or really obscure file systems like "Andrews File System" or support to run IP across amateur radios (AX.25) by default? We recently joked that we should start a pot you add a euro to whenever you find ancient discontinued tech you never heard about our systems support so we can have some nice dinner after this.

I do understand that going full Gentoo or Arch as a generally available distro is not feasible. I am also personally intimidated by compiling my own kernel with just what we need. But the amount of strange ancient things supported by default is also quite ridiculous.

It may actually be the opposite.

Debians steady and professional approach on shipping security patches with very little to no functional difference actually enables us to consider and work on automated, autonomous weekly or faster patches of the entire fleet. And once that's in place and trusted, emergency rollouts are very possible and easy.

We have other projects that "move fast and break things" and ship whatever they want in whatever versions they want and those will require constant attention to ship any update for a security topic. These projects require constant human attention to work through their shenanigans to keep them up to date.

Maybe the more regularly used kernel code has a lot of low-hanging security topics shaken out of it already.

And second, I'm indeed wondering what a good path to minimize the loadable kernel code is on a system looks like. My container hosts for example have a fairly well defined set of requirements, and IPSec certainly is not in there. So why not block everything solely made to support IPSec? I'm sure there is more than that.

After all, the most reliable way to higher security is to do less things.

Wacken got really bad a few years ago. Like, it's normal to rain here, and it's normal for cars to not get off campground, so a dozen of farmers or two are around with their tractors to evacuate people back to asphalt. Except that year, the rain escalated to badly that cars sunk deep enough into the mud that their undercarriage sat on the ground and the mud started to seep into the belly and the engine area.

At that point, dragging the car out has a decent risk of ripping rather important resources out of the rig, and then you got a scrapping job left. That was a fucking mess. They also closed off the Autobahn near Wacken that year, because the massive amount of mud the cars dragged onto the Autobahn turned into a rather slippery affair -- and hitting slippery mud at 100km/h, 60mph without expecting it can easily turn into a life-changing ad-hoc roller coaster.

Doing all of that at your distances in the middle of fucking nowhere would not be enjoyable or fun. Folks drowning in mud in northern Germany is now mostly a funny story among metal heads and rescue folks.

Due to that, a careless installation of a few new dev-systems under the new docker version immediately blew up storage usage on the root-disk, while happily ignoring hundreds of gigabytes on a volume on /var/lib/docker.. because that's where it needs the storage, right? A few older systems also were upgraded but didn't, which was quite confusing at first.

Sorry for being salty, but that was a pretty hectic afternoon with those new agents trashing builds, and now we have a pretty annoying migration plan to plan for the rest. And yes yes it's just a reinstallation, but we have other things to do as well.

Piracy may be a problem, but that's a problem to customer who were willing to give a company money. We stopped buying anything with SecuROM on it after 1-2 of those situations.

I'm aware I will probably lose it, but I'm also anxious to touch it. Maybe I should just get myself some good coffee tomorrow and get over with it. Biggest learning of that save is also how careful and defensive you have to play if you want to consistently get further.