-- Leo's gemini proxy
-- Connecting to thrig.me:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
"Attack surface" is how much surface area something presents to attackers, on the notion that more surface to attack means more ways to get in. Software to be fair does not have a surface, but it does get attacked, so software that can be attacked in many different ways is characterized by something that makes it attackable. Bloat, perhaps, but bloat does not exist. The absence of not-bloat aside, there tends to be a lot of code and dependencies in software that has a large attack surface.
An example of attack surface might be a castle, only they've put in a large number of windows for the wall paper. There's a mighty big courtyard where a whole regiment of paratroopers could land, and if your universe lacks paratroopers, above, try instead the extensive catacombs and secret passages, below. There are only three walls on this castle; the back is some hilly terrain that no attacker could make their way down.† Or maybe only two walls if you account for the sprawling amusement park built up along the western edge. The front gate? It works aright, but the gatekeeper has been having mental health issues, as is all too common in this most modern and advanced of societies. This castle, needless to say, presents a large attack surface. Maybe you are using it at this very moment.
Some folks suffer from the notion "if it is new, it must be better". And so they rush out (and are encouraged) to get all the latest updates, because you wouldn't want to be one of those cavemen who live in the 80s, now would you? The spam (advertising) industry probably bears some blame here with their model year changes, planned obsolescence, and other such blessed innovations. Mention your use of the not-so-modern operating system OpenBSD and you may see responses such as:
< zgu> the abacus was used back when julius caesar walked the
earth. bsd still has a few more decades until they
discover slide rule technology
The discussion had spawned from the fact that OpenBSD's head(1) is not bloated with a "-c" flag so therefore at a quick glance the exploit code in some library would fail on OpenBSD. This very same library was elsewhere being downgraded to an older version, a version that presumably dates to back when Julius Caesar walked the Earth.
To be fair, I do consider Linux to be something of a Clown Show on account of having tried to support it in production for a year or two, so some amount of flyting is to be expected between me and the Linux clan. That being said, the argument that just because something is new makes it better holds no water here.
Maintaining stuff isn't generally résumé enhancing, while making newer and bigger "I Can't Believe It's Not Bloat!" is. See for example the glorious CPU, memory requirements, and attack surface of the modern web. I've heard rumors that corporate policy is to avoid libraries that do not show recent and active commits, which probably touches on the fashion trends, above, or is otherwise idiotic as there's plenty of old code that still gets the job done. Any actual maintenance work here might be to simplify the code, like maybe that massive cmake build dependency could be replaced with a very small Makefile?
$ egrep 'lzma|libarchive|xz' /usr/ports/devel/cmake/Makefile
LIB_DEPENDS = archivers/libarchive \
Corporate policy would, for example, forbid installing Perl modules, but was totally okay with a perl script being installed (that had all the modules packed into it). Modules + script or script + Modules is about the same attack surface, only there's some security theater that prevents one form and not the other. Still, you do want to review all those dependencies, which is generally tedious and not résumé enhancing work. Some of this could be automated, like having better diffs or analysis for code that should not be, but ideally several different people would need to read and understand and approve the changes.
Or maybe the documentation for the old code could be improved? Another desirable and in-demand activity most loved by programmers.
It turns out a -lsystemd include, which brings in some amount of code, and maybe various dependencies, can be replaced with not much code if all your daemon needs to do is inform systemd that it has started. In this future year of 2024 I find myself lacking a system that supports systemd, but the following code is hopefully less worse than the code I found on the orange site.
#ifdef SYSTEMD
const char *path = getenv("NOTIFY_SOCKET");
if (path) {
int fd = socket(AF_UNIX, SOCK_DGRAM, 0);
if (fd < 0) { abort(); }
struct sockaddr_un addr = {.sun_family = AF_UNIX};
size_t len = strlen(path);
if (len >= sizeof(addr.sun_path)) { abort(); }
strncpy(addr.sun_path, path, sizeof(addr.sun_path));
connect(fd, (struct sockaddr *) &addr);
if (write(fd, "READY=1", 7) != 7) { abort(); }
close(fd);
//unsetenv("NOTIFY_SOCKET");
}
#endif
Season with error handling to taste, etc.
Now if you have multiple people tied down reviewing changes, would that not slow down the rate of software change, and increase costs? Probably! Is that a bad thing? This depends on who you ask; first to market often wins the money race, and some are greedy for the latest changes. Meanwhile, a slower rate of change may prevent bad code from hitting production, and may help not wake sysadmins up at hours when we would much rather be asleep. Some people want what they see as essential features and not-bloat; others do a `chmod -x dbus*` to prevent whatever that Desktop Bus thing is from running. One solution here is to agree to disagree, as a conversation I had with a LISP programmer ran something along the lines of
Me. I chmod -x dbus*
Them. But that would break dbus!
Me. Yes?
Them. But software uses dbus!
Me. What for?
Them. Desktop services?
Me. Meh.
Disagreeing can become problematic if some bad technology or the other (Windows, the modern web, the smartphone) is made mandatory for a population. Constructive replacements might be simple, robust, and open protocols that are easy to implement and verify, but that's generally not the direction the wind is blowing.
—
† Except for when some shepherd shows the Persians or the Romans or whomever a goat path.
> At this point, Flamininus is approached by a local shepherd who knows a path around the back of Philip’s position (because his army is sitting in that shepherd’s pasture; note that Philip is not on his home territory so the locals are not friendly) and Flamininus decides to risk it, aggressively skirmishing over two days to keep Philip’s attention while a detachment of his troops, 4000 infantry and 300 cavalry, wound their way down the paths. Philip’s camp was fortified on the level-ground, but he had used the heights essentially as his back wall – a practice Polybius notes is common among Greeks (and Macedonians) and is deeply critical of (Polyb. 18.18) – so the Romans are going to show up behind Philip’s front defenses, essentially inside of his fortifications by coming down from the heights that serve as his back wall. Once in position, those troops are to raise a smoke-signal, leading to a general engagement.
-- Response ended
-- Page fetched on Tue May 21 19:06:35 2024