Replies

• 

  Kristianz428@social.lol

  Oct 21, 2026, 8:18 PM

  (Also, today, sooooooo 🤏 close to just filtering away half of the tech bubble in my timeline because today /these/ things are hard to impossible to bear and I'm at some point just thoroughly ... astounded to see how incredibly easy most answers are and how much complexity, community dynamics and all the drawbacks linked to the ideas of volunteers maintaining huge, complex pieces of code in their spare time.)

  💬 0🔄 1⭐ 3
• 

  Thomastg9541@mas.to

  Oct 21, 2026, 8:30 PM

  @z428 The threat dynamics has changed, again. Defense will have to get even more creative in this arms race, or else one has no choice but to move to commercial platform providers.

  💬 1🔄 0⭐ 0
• 

  Kristianz428@social.lol

  Oct 21, 2026, 8:36 PM

  @tg9541 I still have a little hope here and there that at some point common sense and community values might make it and people will understand that these challenges just can't be addressed in a meaningful way in an environment built around fragmentation and hyper-individualism. It seems to ask for digital solidarity. Solving problems together, to the point of making sure it's not just one or two but maybe half a dozen or more folks who could get active in such a scenario... .

  💬 0🔄 0⭐ 0
• 

  Thomastg9541@mas.to

  Oct 21, 2026, 8:44 PM

  @z428 standardization is a good thing, but it doesn't mean that complexity just goes away. On the contrary, it keeps seeping in from any angle that's not carefully managed. Most often the effect of more people is more abstraction. More abstraction, from this perspective, means more complexity.

  Keeping it dependable through simplicity/frugality is the answer few people want to hear.

  💬 1🔄 0⭐ 0
• 

  Kristianz428@social.lol

  Oct 22, 2026, 5:29 AM

  @tg9541 Ah, yes, that of course too, but I see another aspect to this: Specifically when talking selfhosting, there seems too often too much focus on the technical aspect of things. Like, that whole yunohost aspect, the very message of this is: Why don't you host your stuff yourself? It's easy as pie, just take our packaged system and here you go. It tricks people into thinking that getting an installation up and running from a technical perspective is the challenging thing that can be eased by adding yet more technology (and complexity). Issues like php2shell, that log4j exploit a couple of years ago, ..., should make people aware there's another dimension to that, the process issue. Like: If you run services you or even other users depend on, you want to keep yourself up to date to know about CVEs, especially really critical ones, right on time, every single day of the year. And you need to make sure once something like this pops up, which could be at the worst possible moment in your schedule, you or someone else needs to immediately (and, ideally, with little to no additional communication required) take care of that, even on New Years Day at 1:22am in the morning. That's not technology at all. That's process. That's being aware of exactly these issues. And it's more about forming teams, about making sure, in example, instances of federated services, of communication systems like Matrix or XMPP, ..., are run by a group of people not just an individual. And on the other side, it's something to probably make users aware of when choosing instances of such services for their own use - before you sign up with some services, try to figure out how many people are in charge of it, how do they handle their administrative procedures, ... . Which is tough, I guess. And it's not just something the FLOSS or open network/infrastructure crowd has a tough time addressing, I know more SMEs than I'd like who are proud to have "digital autonomy" because they keep their stuff on-prem and do have "an administrator" take care of all that. The very moment this is actually one person, you're essentially screwed and just didn't learn that yet.🙈 (For the open network, however, I have hopes that this vast vast amount of small and extremely small instances that yet are more than single-user-instances of whichever services comes to mind eventually are a bit consolidated into systems that are maintained by groups or communities not individuals. But I am ... rather unsure. )

  💬 0🔄 1⭐ 0
• 

  Thomastg9541@mas.to

  Oct 22, 2026, 9:36 AM

  @z428 You have a point there. Back in 1997, when I first configured a Linux Sendmail and dnsmasq box to bring 20+ people in an SME into the "Internet" (a 486DX with a few MB of RAM), I soon learned that no box was too small to be exploited, even on dial-up!

  How might an architecture for shared administration / shared autonomy look like?

  There is an analogy for the plain packets and some of the desktop application security, e.g., the Debian packet system.

  Operating infrastructure is a different cup of tea.

  One thought: any reduction of variance creates a massive target - shared maintenance of infrastructure is no exception. Creating minor targets changes the scenario.

  Thoughts?

  💬 1🔄 0⭐ 1
• 

  Kristianz428@social.lol

  Oct 22, 2026, 11:59 AM

  @tg9541 I've been pondering this a lot. In recent months with some of our customers, I experienced them enforcing rather strong security guidelines internally. Such as: There's network monitoring software doing regular checks of services and hosts, and in case there's software ridden with CVEs, owners of this software are provided with a grace period to migitate this until network operations will quarantine / shut down the system. This has been a pain in the back for us but I pretty much understand why people do that.

  From that perspective, and looking at an issue like php2shell, I wonder what would happen, globally, if we had a shared agreement on CVE severity and if, say, ISPs or hosting providers were allowed to act just like the corporate IT above: Identify critical services in your network, provide people running these with a notification and a grace period and if things aren't fixed within a reasonable timeframe (weeks for less critical, days for critical, hours for severe issue), services are strictly separated from public network. What would such an approach change in developer communities, in communities running distributed infrastructure, ... ? There have been loads and loads of situations in my professional past (wrestling DDoS attacks on our infrastructure mainly run by poorly maintained and exploityed typo3 installations), and a lot of these I would have preferred to avoid.

  (Not sure here. I get that aspect of variance being helpful in terms of limiting blast radius if variants differ, but for the PHP thing in example, it seems every version in every package for every operating system family and version is affected so apparently variance doesn't help. And as long as we don't have software that is somehow formally verifiable, as long as we don't have software, protocols, algorithms, infrastructure that is built using safe technologies, processes, ..., we'll be repeatedly facing those issues. So ... maybe focusing on getting severe issues fixed on a majority of affected systems and optimizing all procedures, flows, ... surrounding this seems a tempting idea.)

  💬 0🔄 0⭐ 0
• 

  Thomastg9541@mas.to

  Oct 22, 2026, 5:33 PM

  @z428 The last time I worked on PHP systems was 22 years ago...

  With every new major wave of exploits, with every new known vulnerability I wondered by when it would finally be obsolete. Most likely it is a good fit for a class of software that's viable just because of PHP. A re-write, e.g., in Rust might be an option (but only if the potential for vulnerability isn't part of the feature package).

  This said, I believe that specific legal frameworks might force infrastructure service providers to shut vulnerable services down, but such things are full of ambiguities, and conflicts of interest: what's more important, an Internet service that's vital to some, or the abstract risk of a vulnerability? In fact, the risk assessment is best done by the party that configured a server; it's also possible to harden the underlying OS.

  💬 1🔄 0⭐ 0
• 

  Kristianz428@social.lol

  Oct 22, 2026, 5:45 PM

  @tg9541 I'm still using PHP without much pleasure but knowing, still, it's widely common and relatively easy to use and most likely the easiest solution if you want to do some slightly more dynamic web stuff on systems that are shared hosts and don't require you to run a root server all on your own. I dislike the fact that PHP still in 2026 is the tool of choice for that but well here we are. 🙈

  As for legal frameworks and security... I agree it's a slippery slope and I probably wouldn't applaud it. That said however, I'm more than just then and now a bit ... disturbed to see how many services are, like, just "brought up" by someone one day and then eventually left running, never maintained, never updated, never fixed. Also I'm not pleading for strictly shutting down services that aren't patched or updated but I'd really fancy a procedure that ... urges an administrator of whichever piece of infrastructure to be available, to respond to those issues and to, at the very least, take rudimentary measures of migitating their stuff, protecting their data, maybe doing backups, cleaning things up, sunsetting services no longer needed on their own. If an internet service is vital to someone, this kind of actual, visible administration is something I'd just definitely expect to see.

  💬 0🔄 0⭐ 1
• 

  Thomastg9541@mas.to

  Oct 22, 2026, 5:49 PM

  @z428 I fully agree. Hobby projects should stay in a homelab, never exposed to the Internet. But then there is also unmaintained routers, vulnerable "smart" TVs, trash-grade IP-cameras, etc., etc.

  The Internet was never designed for this. But here we are.

  💬 0🔄 0⭐ 0