c0l0

IANAL, but afaik, copyright licenses can only ever affect (re)distribution - not use.

According to my ~15 years of work experience in IT/the tech sector, this ought to be pretty accurate.

I will go on the record here and one-up them, warning against the use of any antivirus product. SO many vulns and gaping, smoking holes in that kind of software over the years, it's not even funny. Faux-security is what most vendors are peddling.

https://twitter.com/GossiTheDog/status/1427935182200492039 is one of my favourite bugs from recent years. I acknowledge this bug is not specific to an antivirus product (but of course, Fortigate offers that as an optional component for traffic inspection - and I keep wondering what that sub-component's code quality is like 8-)), but anyone who tries WILL find examples for grave problems aplenty.

HTTP Basic Auth over a secure transport (i.e., TLS) is not a "security issue".

I am worried that the supreme arrogance of abstraction-builders and -apologists that this article's vernacular, too, emanates will be the cause of a final collapse of the tech and IT sector. Or maybe I even wish for it to happen, and fast.

Everything gets SO FRICKIN' COMPLEX these days, even the very simple things. On the flip side, interesting things that used to be engineering problems is relegated to being a "cloud cost optimization" problem. You can just tell your HorizontalPodAutoscaler via some ungodly YAML incantation to deploy your clumsy server a thousand time in parallel across the rent-seekers' vast data centers. People write blogs on how you can host your blog using Serverless Edge-Cloud-Worker-Nodes with a WASM-transpiled SQLite-over-HTTP and whatnot. This article's author fantasizes and fetishizes interconnected lanscapes of OpenID-Connected workloads that are, and I QUOTE, "stateful applications that are stateless". Because "This means data should be handled externally to the application using other abstractions than filesystems, e.g., in databases or object stores." - yeah, fine and dandy, but which platforms of the future should these services be hosted on? And who will develop and shepherd and maintain and fix them?

I run and use https://resolv.us.to/ - you may do the latter, too.

When I worked in (quasi-)SRE at a somewhat busy and popular EU-based website, we "invented" our own HTTP header namespace (think like the "X-"-prefix that you see in the wild for "non-standard" HTTP headers, that often end up as ossified de-fact-standards without much of an RFC to specify them) for stuff that our internal infrastructure components, like the HTTP- and HTTPS-terminating reverse proxies, would add.

The systems involved took proper care that those headers and their values really came from us, and not some outside system. Of course, we also had some header akin to Our-Site-Prefix-Peer-IP-Addr, to know which TCP peer the outermost system was actually talking to. In combination with evaluating other headers, like the X-Forwarded-For that this article handles in delightful detail, there was a lot of interesting detective work to be had in terms of which clients tried to spoonfeed us which kind of would-be-spoofed data.

These days, Carrier-grade NAT and the slow death of the End-to-end principle make these techniques woefully inadequate to discern between "legitimate" use, and clients you'd rather keep out. Sadly.

I think it is foolish to try to predict what Russia/Putin is up to once Ukraine has been dealt with (which, I assume, it/he will have achieved at some point in time). There are numerous reports of fact as well as opinion pieces published over the decades since the fall of the SU by esteemed and respected strategists which or who pointed at/predicted Russian military intervention, if NATO did not call off its eastward expansion plans. We have arrived at that point in 2008 already, and then again in 2014, and now finally also in 2022.

For those wanting to involve NATO and set off WW3 along with the nuclear apocalypse, I wonder - why the rush? We can still nuke this planet's civilization to scraps after Russia's/Putin's plans for re-establishing the "Great Russian Empire" have materialzied - or rather, if they actually do.

Please excuse my cynical undertone, but this reckless calling for intervention that may very well lead to a kind of catastrophic escalation that human history would never ever recover from REALLY scares the shit out of me :(

I've argued this stance once before, but I feel it needs reiterating on this topic: I for one am 100% convinced that whatever the (FOSS) software future has in store for the world MUST have strong support for dynamic linking.

If you look at something like `apt-cache show podman | grep ^Built-Using:` (Output: https://paste.debian.net/plain/1225449) on Debian 11, you will see why. Imagine a few of those components shared between tens of packages, and security problems discovered im some. It's got to be any package maintainer's worst nightmare. "Traditional" distros run by volunteers and in participation of small-ish companies will not be able to cope with that kind of need for rebuild churn - and yet they will live amongst us for many years, if not decades, to come.

I wish this misguided notion regarding "inofficial strict mode" would go away, as `set -e` is suboptimal (and can be very tedious to deal with on top of that): https://mywiki.wooledge.org/BashFAQ/105

It makes sense to opt into errexit for select blocks/sections in scripts and under certain circumstances, but having it default-on is a recipe for quite a bit of head-scratching in the future.

And boom, you have two sources of half-truths.

I admit I hated this ZFS feature in Solaris 10 already, and it was the reason for more than one unaccounted leftover NFS share that ended up in bright red in audit reports.

Cool; when are we going to get rid of the "API key" then?

Cool story! I can only imagine how good the person solving the riddle felt when the penny finally dropped! :)

Two somewhat topical observations in a similar vein:

Back in a sysvinit world, many (Debian) users would run init-scripts directly via `/etc/init.d/someservice someaction`, instead of using `/usr/sbin/service someservice someaction`. This could have very unpleasant side effects at times, because `service` is/was actively trying to clean and sanitize the resulting child processes' environment, while most init scripts themselves usually did not.

The second thing that the article made me think of is not directly related to most "admin wants the system to start a service"-scenarios, but COULD also happen in such a situation: On Linux, when a process tries to fork, the kernel requires certain guarantees in terms of usable memory for the process' copy, due to copy-on-write semantics for allocated pages. If these cannot be matched, forking might fail with ENOMEM. In my experience, this is much more likely to happen when the process trying to fork has a lot of allocated memory accounted for. Therefore, it makes perfect sense to have a "lightweight" kind of fork-and-exec-server around in the system that can be contacted via an IPC mechanism, and made to start daemon processes that are probably not meant to inherit anything from the caller's environment (like file descriptors, niceness, environment variables) in the first place.

My bad, I actually had the "production" trace command set to look for `XGetSelectionOwner`, but mis-pasted into my comment ;) Will that fare any better? It did make a few more PIDs/culprits end up in the trace output for me after all.

You are correct that "bringing your own function"/shared object will break that particular bpftrace script, but I would assume one could find a way to set up a probe in the X server, where all clients messing with clipboard state via some kind of IPC have to pass thru? (Again, I can only wildly speculate how X11 works under the hood - kinda shameful that I never bothered to look over all these years :-S )

I think Linux dynamic user probes would lend themselves quite well for something like this. Fooling around with bpftrace for a few minutes yielded this one-liner, which catches all the conscious X11 selection accesses (and a few unconscious ones, too :)) I provoked on my desktop during a few minutes of testing:

    sudo bpftrace -e 'uprobe:/usr/lib/libX11.so:XGetSelectionOwner{time("%H:%M:%S ");printf("%-6d\n", pid);}'

I am not familiar with Xlib/X11 at all, so I am not sure which library functions one would be most interested in to explore this much further.

Edit: Replaced `XSetSelectionOwner` with `XGetSelectionOwner` in bpftrace invocation.

Let me elaborate on the problem I do have with remote attestation, no matter if I can verify that the signed binary is identical with something I can build on my own.

I use LineageOS on my phone, and do not have Google Play Services installed. The phone only meaningfully interacts with a very few and most basic Google services, like an HTTP server for captive portal detection on Wifi networks, an NTP server for setting the clock, etc. All other "high-level" services that I am aware of, like Mail, Calendaring, Contacts, Phone, Instant Messaging, etc., are either provided by other parties that I feel more comfortable with, or that I actually host myself.

Now let's assume that I would want or have to do online/mobile banking on my phone - that will generally only work with the proprietary app my bank provides me with. Even if I choose to install their unmodified APK, (any lack of) SafetyNet will not attest my LineageOS-powered phone as "kosher" (or "safe and secure", or "healthy", or whatever Google prefers calling it these days), and might refuse to work. As a consequence, I'm effectively unable to interact via the remote service provided by my bank, because they believe they've got to protect me from the OS/firmware build that I personally chose to use.

Sure, "just access their website via the browser, and do your banking on their website instead!", you might say, and you'd be right for now. But with remote attestation broadly available, what prevents anyone from also using that for the browser app on my phone, esp. since browser security is deemed so critical these days? I happen to use Firefox from F-Droid, and I doubt any hypothetical future SafetyNet attestation routine will have it pass with the same flying colors that Google's own Chrome from the Play Store would. I'm also certain that "Honest c0l0's Own Build of Firefox for Android" wouldn't get the SafetyNet seal of approval either, and with that I'd be effectively shut off from interacting with my bank account from my mobile phone altogether. The only option I'd have is to revert back to a "trusted", "healthy" phone with a manufacturer-provided bootloader, firmware image, and the mandatory selection of factory-installed, non-removable crapware that I am never going to use and/or (personally) trust that's probably exfiltrating my personal data to some unknown third parties, sanctified by some few hundreds of pages of EULA and "Privacy" Policy.

With app stores on all mainstream and commercially successful desktop OSes, the recent Windows 11 "security and safety"-related "advances" Microsoft introduced by (as of today, apparently still mildly) requiring TPM support, and supplying manufacturers with "secure enclave"-style add-on chips of their own design ("Pluton", see https://www.techradar.com/news/microsofts-new-security-chip-...), I can see this happening to desktop computing as well. Then I can probably still compile all the software I want on my admittedly fringe GNU/Linux system (or let the Debian project compile it for me), but it won't matter much - because any interaction with the "real" part of the world online that isn't made by and for software freedom enthusiasts/zealots will refuse to interact with the non-allowlisted software builds on my machine.

It's going to be the future NoTCPA et al. used to combat in the early 00s, and I really do dread it.

I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

It may not exactly be what you are looking for, but if you want to protect a stable data set from bit-rot after it's been created, make sure to take a look at Parchive/par2:

https://en.wikipedia.org/wiki/Parchive

https://github.com/Parchive/par2cmdline/

Because documentation is what is needs to be: A simplified and necessarily incomplete description of program behavior. It's a trade-off, since a complete and exhaustive description of all intricacies of potential program behavior would be at least as complex as the definition (= its source code) of said program.

If you happen to have a question that ends up on the wrong side of that trade-off between documentation's completeness and accessibility, you will have to descend into the depths that lie beneath. I believe the redis documentation actually strikes a rather OK balance in that regard.

I don't want to sound snarky, but since you mentioned that Redis does not document if/that "multiple key expiry is guaranteed to occur at the same time if keys have the same EXPIREAT setting", I am tempted to ask - why did you not check the implementation you're using? That's the unique selling point of using FOSS - you don't have rely on documentation or observational guesswork - you can wade in and really see for yourself! Redis' source code is especially readable in my opinion (thanks again, antirez, for creating this little load-bearing gem of a data structure server), so I would very much encourage you to try, even if C is not your particular forte :)

My advice: On eBay (or any other platform that makes it easy to buy used hardware components), go look for "sas2008 4e", and check out the offers. You should be able to get a decent HBA driven by mpt2sas/mpt3sas for around 40 to 60US$.

I recently started looking into using an LTO-7 tape drive that I got handed down, along with a few dozens of pristine LOT-6 tapes, for archiving purposes. I got to play around a bit with SAS HBAs, and was kinda shocked how much of a difference that can make in the user (or shall I say sysadmin?) experience: LTO-6 tapes are spec'd to transfer rates of around 150MB/s, so well within the reach of even the the first SAS gear generation. However, the very first SAS HBA with external SFF-8088 connector I managed to get my hands on (an LSI SAS1068e) topped out at a disappointing 80MiB/s, no matter what I tried in terms of blocking and buffering. Switching to a more modern (but still old) LSI SAS2008-based HBA got me close to the theoretical maximum.

Then there's the (to me, still open) question of how to best use the actual tape storage capactiy... Since my hardware is newer than LTO-5, LTFS (https://github.com/LinearTapeFileSystem/ltfs) is an option for convenient access, especially listing tape contents, but that could make it hard for other people down the line to restore data from the tapes I create.

It's probably safest to assume that tar will always be there, at least wherever there's tape, too. GNU tar also handles multi-volume/-tape archives, which seems like a necessity if you need to back up amounts of data that exceed a single tape's capacity. Then again, if you want to use encryption with actual tar (important for the kind of data I need to archive), your only option seems to be piping the whole archive through something to compress the stream, which will make accessing individual records in the archive opaque to the drive itself... and you can't just dispose of individual keys to make select parts of the archived data go away for good, either.

Also, I would like to conserve as much tape as (conveniently) possible in my archiving adventure. There's "projects" (i.e., top-level directories of directory trees) that consume more than one tape of their own, and then there's smaller projects that you can bin-pack together onto tapes that can fit more than one such project.

I've started implementing a small python wrapper around GNU tar to solve a number of these problems by bin-packing projects into "tape slots" and also keeping track of tape-to-file mappings in a small sqlite database, but a workable solution for the encryption problem(s) is not something I managed to come up with yet... If someone has an idea (or better yet, a complete and free implementation of what I am trying to hack together :)), please be so kind and let me know!

I am pretty certain that

> I can't help but think this trend will damage shared knowledge in the long run.

is an understatement. There will be a few people in the know on how to run "the cloud", and lots and lots of people consuming their services, at bewildering premiums.

Sure, most software projects and products have their share of flaws and bugs :)

I do not claim ZNC or our whole IRC setup was perfect, but for me and many others, it did a very decent job of providing effective, no-frills, getting-things-done means of communicating, all while consuming little resources on both server and clients, and being simple, underestandable, and easy to hook other software into.

I really miss it, and personally dislike (especially the client UX of) most trendy/recent alternatives.

We had an internal instance of ZNC for human users to connect their clients to (at their option - but that was the documented and preferred way of getting onto the IRC network). Creating ZNC user profiles was part of the semi-automated onboarding/setup procedure, whilst ZNC authentication was done against the dovecot IMAP/SASL server we had for email. More casual IRC users in the company (marketing etc.) usually preferred to use an intranet-hosted web application (The Lounge) to access it from their browser, while most IT people had native clients of their choice set up (hexchat, irssi, etc.). Worked well.

Maybe that wasn't possible/enabled for our particular deployment (that was in the IT dept. of a big European bank), as we had what I've been told was a strange bastardization of O365 and other MSFT services - a mix of on-prem and cloud services unlikely to be found elsewhere.

At any rate, for the IRC server at the shop I was at previously, I had "webhook" support/a http(s)->irc gateway implemented on my own in much less than an hour via CGI ;)

A number of moons ago, I switched from a company that used IRC for its internal, real-time, ephemeral communication needs to an enterprise shop that used Microsoft Teams to do that (and of course other communication stuff, as the boundaries for what was better kept in Sharepoint, Confluence, Email/Exchange, the legacy Wiki, and/or Teams were never quite clear :)) there.

In the old shop, we eventually had all kinds of important subsystems hooked up to our internal IRC server: Monitoring and alerting. Source control and Wiki activity. The deployment pipeline. Ticket activity reports. All these services were pretty much effortlessly set up to provide useful, real-time status information broadcast to topic-specific channels users could idle in. Everyone could stay informed on topics of their interest, in real time, with no barrier to entry. It was really good, and the implementation completed in a few hours total, for all use-cases, due to irc's incredible simplicity.

Due to the benefits I had reaped from that setup before, I tried to implement parts of it on/for the MS Teams platform at the then-new job. Getting the Teams Python SDK to implement a bot-like entity running alone proved to be a days-long ordeal, and whatever followed wasn't much more pleasant.

In the end, we let someone set up two email-to-teams-channel-forwards which kinda worked, but suffered from obnoxious, multi-minute relay delays.

As a consequence of the tedious bringup and the latency shortcoming, the "effortless notification" initiative never really got traction.

Not only because of this particular experience I am a firm believer that software/system simplicity is a virtue that can neither be overstated in importance, nor substituted by anything else.

Which processes systemd allows to live on after stopping an associated service depends on the kind of KillMode= (see systemd.kill(5)) that was specified for the service unit. The default ('control-group') is usually what you want, esp. if you are looking to not recreate the kind of chaos improper process management SysV-style init scripts frequently caused.

Chances are the k3s service unit specifies something else (like 'none') - whether or not that is actually wise would probably require some research.

I guess one can work around the lack of dynamic linking in a language like Go on the package manager and/or distro level (though some established distros and package management ecosystems, which I very much hope will not go away, will have it harder to adapt than others), but I really would like to make everyone think about whether we should...

Imagine a Debian archive (that is, a few tens of thousands of packages with source, build recipies and binaries for multiple architectures available) with only static linking on the table. You got a few hundreds to thousands of those packages installed on typical, real-world Debian machines. Then, a central component like zlib or OpenSSL gets an important patch. This triggers hundreds, if not tens of thousands (transitive library .so dependencies are a thing after all, and you want to have all your supported arches covered) of rebuilds across the archive. All users will have to re-download and re-install all resulting upgraded packages they have installed.

With increased sharing of source code (i.e., when following "don't build your own crypto!" and other generally useful mantras by re-using existing codebases) and only static linking on the table, this kind of problems gets really, really bad really quickly for large-ish software archives. Kinda like with log4j in the Java ecosystem, where each app is used and event expected to dragging all its runtime dependencies along on its own.

In the dylib world we are living in right now however, users get a single updated package, and upon the next restart of an application linking against it, they're immunized against the bug. The reduction of churn is nigh-unfathomably massive.

If your systems generally only run a single application, and there's a dedicated ops team at the top (or bottom - it's a matter of perspective, I guess :)) of a monorepo world with each dependency fully vendored in, and an "intelligent" build and deployment system atop it all that will take care of gracefully upgrading everything everywhere upon such routine patching, I can see how statically linking everything reduces the amount of potential pain points upon deploying stuff. For the significant portion that makes up the rest of the world, they generally don't have such luxuries, and will be a lot worse off. Especially established and wonderful Free Software communities like Debian or Fedora. I think that would be a huge sacrifice to make.

Language preferences and safety features aside, I for one am 100% convinced that a/the upcoming language to rule "systems programming" (in a FOSS world with community participation) MUST have strong support for dynamic linking.

If you look at something like `apt-cache show podman | grep ^Built-Using:` (Output: https://paste.debian.net/plain/1225449) on Debian 11, you will see why. Imagine a few of those components shared between tens of packages, and security problems discovered im some. It's got to be any package maintainer's worst nightmare.