To update, or not to update, that is the question?

[dos2unix]

To Update, or Not to Update — That Is the Question

If you're running Arch or Fedora, this question practically answers itself. Both distros move fast, and if you're paying attention, you likely have packages waiting for you every day or two. But not everyone rolls that way — and honestly, this article isn't really aimed at you Arch and Fedora folks. You already know the drill.

This one is for the users who installed their distro six months ago, hit "update" right after the install, and then... went on with their lives. Maybe it's been a year. Maybe longer. Maybe you're thinking, "I'm not running a server. I'm behind my ISP's router. Nobody's targeting me." And you know what? You're probably right about all of that.

So let me give you a different reason to update.

The Biggest Hacker on Your Computer Is You — and Your Browser

No, I'm not calling you a hacker. What I mean is this: the most dangerous thing most home users do on their computer is browse the web. And the browser has become an extraordinarily complex attack surface.

We've talked about this before in various articles and threads, but it bears repeating because it isn't getting better. It's getting worse.

Modern browsers execute JavaScript from thousands of sources. They store cookies from sites you visited once in 2019. They expose GPU-accelerated rendering APIs that can be used to fingerprint your hardware with remarkable precision — a technique called GPU fingerprinting that doesn't require cookies, doesn't require login, and can't be blocked by most conventional privacy tools. There are also multi-factor authentication bypass techniques — sometimes called adversary-in-the-middle attacks — that intercept session tokens rather than passwords, making even 2FA-protected accounts vulnerable when the underlying browser session is compromised.

Browsers haven't gotten more secure in the ways that matter most to ordinary users. In many respects, they've become more capable and therefore more dangerous as platforms for delivering malicious code.

"But I Keep My Browser Updated"

Great. That actually does help. Browser vendors — Mozilla, the Chromium project, the folks behind your favorite fork — do push security patches, and keeping the browser itself current is genuinely worthwhile.

But here's the thing: your browser doesn't run in a vacuum.

It calls on system libraries. OpenSSL. libcurl. libwebp. glibc. The list is long and the names mostly unglamorous, but these libraries sit underneath everything your browser does with the network, with images, with certificates, with memory. When a vulnerability is discovered in one of them — and they are discovered regularly — updating your browser alone doesn't fix it. The fix lives in the system package, and if you haven't run "dnf update" or "apt upgrade" in eight months, you don't have it.

Remember CVE-2023-4863? That was a critical heap buffer overflow in libwebp — the library used to decode WebP images. It was being actively exploited in the wild, it affected virtually every major browser, and the fix required updating the underlying system library, not just the browser. If you updated your browser but not your OS packages, you were still exposed.

That's not a theoretical edge case. That's a real vulnerability, real exploitation, and a real gap that "just update the browser" doesn't close.

A Word About Local Network Security

"But I'm behind my ISP's firewall."

True. And that firewall does block a lot of inbound traffic that would otherwise be probing your machine. What it doesn't do is inspect the content of what you invited in — namely, every web page you loaded today.

Drive-by downloads, malicious ad scripts, compromised CDNs, typosquatted package names — these threats come in through the front door on port 443, encrypted, looking exactly like legitimate traffic. Your ISP's NAT router has no opinion about any of it.

"But I'm Running a Stable LTS Distro — I'm Fine, Right?"

Stable and LTS distros — Debian Stable, Ubuntu LTS, RHEL and its clones like Rocky and AlmaLinux — have a well-earned reputation for reliability. The distro maintainers do a lot of work backporting security fixes to stable package versions without pulling in new upstream features that might destabilize things. That's genuinely valuable, and it's a big reason these distros dominate in server and enterprise environments.

But "stable" does not mean "immune." It means the package versions move slowly and deliberately. The security patches still come, and they still need to be applied. A Debian Stable system that hasn't been updated in a year has a year's worth of CVEs sitting on it, backported or not.

So yes — update your LTS system. The cadence can be a little more relaxed than a rolling release, but "relaxed" means monthly at the outside, not never.

It's Not Just Security

So far we've talked mostly about security patches, but that's only one reason to stay current. Package updates come in a few flavors, and even if you've somehow convinced yourself you're not a security target, the other reasons still apply to you.

Bug fixes. Every distro ships bugs — that's not a criticism, it's just the nature of complex software. Upstream developers find them, fix them, and push the fix into a new package version. That kernel panic you've been working around? The audio driver that drops out every few hours? The application that crashes on a particular file type? There's a decent chance a fix has already been packaged and is sitting in your repo right now, waiting for you to run an update. Why live with a known bug when the fixed version is one command away?

New features and driver improvements. This one matters more than people realize, especially on the hardware side. If you've bought new hardware in the last couple of years — a newer GPU, a Wi-Fi card, a Bluetooth adapter — the drivers for that hardware are actively developed. Newer kernel and driver packages can mean better performance, improved power management, fixed stability issues, and support for hardware capabilities that simply weren't working before. Staying on an old kernel because you haven't updated in a year means leaving potential hardware improvements on the table.

So even if you strip away every security argument entirely — even if you genuinely believe you're untouchable on your home network behind your ISP's router — you're still leaving bug fixes and hardware improvements sitting uncollected. Do yourself a favor and grab them. Running a patched, stable, fully supported version of your software costs you nothing except the two minutes it takes to update and reboot.

Update, Then Reboot

This one catches people off guard, even folks who are diligent about running updates.

Some package updates take effect immediately — a userspace utility gets replaced on disk and the next time you run it, you're running the new version. Easy. But other updates don't work that way. Kernel updates, for instance, don't replace the running kernel. The new kernel is staged and waiting, but your system is still running the old one until you reboot. Same goes for core shared libraries like glibc or OpenSSL — processes that were already loaded into memory when the update ran are still using the old version of that library. They won't pick up the patched version until they restart, and the cleanest way to ensure everything restarts cleanly is a full system reboot.

Now, experienced admins will point out that tools like "needs-restarting" on RHEL/Fedora systems, or "checkrestart" from the debian-goodies package on Debian/Ubuntu, can tell you specifically which running processes are still using old library versions. And that's true — in a server environment where uptime matters and you want to surgically restart only what needs it, those tools are your friends.

But for a desktop or home system? Just reboot. Unless you have a specific reason to know which updates are hot-swappable and which aren't — and that's genuinely non-trivial knowledge — a reboot after updates is the safe, simple, correct answer. It costs you two minutes and guarantees you're actually running what you just patched.

Update, then reboot. In that order. Every time.

How Often Should You Actually Update?

That depends on your risk tolerance and your distro, but here are some reasonable guidelines:

Rolling releases (Arch, Tumbleweed): Update frequently — weekly at minimum. These distros assume you're keeping pace.

Semi-rolling / fast release (Fedora): Weekly is ideal. Fedora moves quickly and backports security patches aggressively.

Stable/LTS distros (Debian Stable, Ubuntu LTS, RHEL/Rocky/Alma): These backport patches to stable package versions, so you may not see version bumps, but the security fixes are there. Update at least weekly; monthly at the absolute outside.

If a zero-day drops: Update that day. Check your vendor's security advisories. This isn't paranoia — it's hygiene.

For what it's worth, in the high-security, high-availability environments I've worked in professionally, weekly patching was the floor, not the ceiling. Zero-day patches were expected within a matter of hours. That culture of urgency exists for a reason, and while you don't need to run your home desktop like a government network, some of that mindset is worth borrowing.

Making It Easy

The best update habit is the one you'll actually keep. A few suggestions:

Set a recurring reminder — "Saturday morning, run updates" — and treat it like taking out the trash.

On systemd-based distros, you can use a systemd timer or a simple cron job to automate updates if you trust your distro's package quality. LTS distros are generally safer for this than rolling ones.

Subscribe to your distro's security announcement list or RSS feed. Most major distros have one, and it's a low-noise way to know when something critical has dropped.

Don't forget firmware. "fwupdmgr update" handles a lot of hardware firmware on supported systems and is worth adding to your routine.

The Bottom Line

You don't have to be paranoid to take patching seriously. You just have to recognize that the threat model for a home Linux user today is meaningfully different than it was twenty years ago. The browser is a massive, complex, constantly-evolving attack surface sitting in the middle of your daily computing life. It depends on system libraries. Those libraries have vulnerabilities. Those vulnerabilities get patched. And beyond security, every update you skip is a bug fix you're not getting, a driver improvement you're leaving on the table, and a feature you'll never see.

All you have to do is apply the patches. Then reboot. It's not glamorous, but neither is explaining to someone why your machine got owned because libwebp hadn't been updated since before your last birthday.

And for you rebels out there — you know who you are — the ones who installed Linux three years ago, updated it once, and have been coasting ever since: part of the reason the real attackers keep finding success is because of systems exactly like yours. Unpatched machines don't just put you at risk, they become footholds, proxies, and pivot points that put the rest of us at risk too. So do the community a favor. Open a terminal. Run your updates. Reboot.

We'll be here when you get back.

 

[dos2unix]

To Update, or Not to Update — Part 2: More Reasons to Stay Current

A few more thoughts to add to the first post, because some good counter-arguments came to mind that are worth addressing.

"But My Distro Is Immutable"

Fair point — immutable and read-only root filesystem designs have become more common and more sophisticated in recent years. Fedora IoT, Fedora Silverblue, and openSUSE MicroOS use OSTree-based or similar technologies where the base OS image is essentially read-only, and changes are layered on top or applied as atomic image swaps. Some of us have even worked with servers that boot from read-only media — DVDs, ROM-based flash, or protected partitions — where the running OS literally cannot be modified by a running process or a piece of malware that manages to get a foothold.

This is genuinely useful. If an attacker compromises a running process on an immutable system, they can't easily persist across a reboot by modifying system files, because those files can't be modified. That's a real security advantage and the design deserves credit for it.

But it doesn't eliminate the need to update — it just changes how updates are delivered.

A vulnerability in a library or kernel doesn't become harmless because the filesystem is read-only. The vulnerable code is still executing in memory. A WebP exploit doesn't need to write to disk to do damage — it needs your browser to parse a malicious image, and it can do plenty of harm in RAM before the reboot that would have cleaned it up. An immutable base image with a three-month-old kernel is still running a three-month-old kernel, with everything that implies.

The immutable model actually makes the argument for updates stronger in one respect — because updates typically come as whole image replacements rather than individual package patches, you can't easily cherry-pick. You update the whole base or you don't update at all. Which means if you've been putting it off, you're potentially further behind than a traditional package-managed system where at least some security updates might have sneaked through.

So yes — immutable distros are a meaningful step forward in system integrity. They are not a substitute for staying current. You still need to pull that new image, apply it, and reboot. The mechanism is different. The discipline required is the same.

It's Not Just Security — It's Your Hardware Too

We touched on bug fixes and driver improvements in the first post, but it's worth expanding on the hardware angle because the examples are concrete and compelling.

NVIDIA pushes new Linux driver releases every few months — performance improvements, bug fixes, better Wayland support, new feature enablement. If you're a gamer or doing any GPU compute work on Linux, staying current on NVIDIA drivers is not optional, it's the difference between things working well and things not working well.

On the AMD side, Kernel 6.19 is bringing improved Radeon GPU code that could deliver performance gains of up to 15% on existing hardware — just from a kernel update. No new hardware required. You already own the GPU. The improvement is sitting in a kernel you haven't pulled yet.

That Wi-Fi chip that showed up as unrecognized or flaky when you bought your laptop last year? There's a reasonable chance a driver landed in the mainline kernel since then and it just works now — if you're actually running a current kernel. Bluetooth adapters, touchpads, suspend and resume behavior, power management on newer CPUs — all of these are areas of active kernel development where staying current translates directly into a better functioning, better performing system.

This isn't abstract or theoretical. If you're sitting on a kernel from eighteen months ago because you haven't bothered to update, you are leaving real, tangible improvements on the table. Not future improvements — improvements that already exist, already shipped, and are already working for everyone who kept their system current.

Puppy Linux deserves a mention here too. It's a fascinating and capable little distro with a loyal following, and its session-based approach to persistence is its own kind of partial immutability — but the same principle applies. The base image ages. The kernel ages. Updates exist for a reason, and even Puppy users benefit from rolling a fresher build from time to time.

The Short Version

Security patches, bug fixes, new features, better drivers, faster GPUs, working hardware that didn't work before — there is no angle from which "don't update" is the better choice. Immutable filesystem or not. LTS or rolling. Server or desktop. Puppy or Arch.

Update your system. Then reboot. You'll be glad you did.

 

[The Duck]

Fist thing every morning prior to using any of the computers is check for updates and install any updates.

I figured that's what you're supposed to do makes for a secure computer and doesn't take but a minute.

 

[wizardfromoz]

Great article Ray.

On

How Often Should You Actually Update?

That depends on your risk tolerance and your distro, but here are some reasonable guidelines:

Rolling releases (Arch, Tumbleweed): Update frequently — weekly at minimum. These distros assume you're keeping pace.

Semi-rolling / fast release (Fedora): Weekly is ideal. Fedora moves quickly and backports security patches aggressively.

Stable/LTS distros (Debian Stable, Ubuntu LTS, RHEL/Rocky/Alma): These backport patches to stable package versions, so you may not see version bumps, but the security fixes are there. Update at least weekly; monthly at the absolute outside.

I am an exception to that rule, because of my unique.circumstances.

Running 85-90 Linux at a time, I only update monthly, rolling, stable or other.

I don't use one daily driver, I may be in 6-8-10 in a day, depending on what I am doing.

Following the running of updates, I reboot and establish all is working fine, then take a Timeshift snapshot, and note in the comments "next due (1 month from now's date)"

Cheers

 

[nolim]

In all my computers (desktop, and even when I had servers in aws that are not always on), I have auto-update script upon startup. Those PC are getting restart frequently, usually within days at max.
I had in the past some very rare events where my system break in the next restart, but it is usually very easy to fix and I'm not afraid.

Here is my auto update script in ubuntu that is being executed by systemd upon startup:

#!/bin/bash
set -e
export DEBIAN_FRONTEND=noninteractive
sudo apt-get update
sudo -E apt-get upgrade -y > /tmp/update.log
sudo -E apt-get full-upgrade -y >> /tmp/update.log
sudo -E apt-get autoremove  -y >> /tmp/update.log
sudo snap refresh >> /tmp/update.log
flatpak update -y >> /tmp/update.log

I also have a similar script for my fedora laptop.

 

[nolim]

Another related question, is how to keep your container inages up to date?
I add the update commands in each image build, but once the image is set, it is not getting updates.

 

[MikeWalsh]

@dos2unix :-

Another "gem", Ray!

You're right about Puppy. Essentially, she's very similar in concept to the current crop of immutable distros. Ya want updated software, you download & install a newer Puppy. It's as simple as that.

It amazes me that Barry K was thinking this way 20-odd years ago...

~~~~~~~~~~~~~~~~~~~~​

The way the current Woof-CE build-system hosted over on GitHub works, you sign-in (this DOES need an a/c to function), go to the appropriate web-page and trigger a "run" of whichever newest Puppy you want. These run in a VM, pull in all current patches/fixes/updates from the 'parent' distros, then execute the build-scripts, and finally spit out a bang-up-to-date ISO.

Download it, install it - a 2-minute job - and run it. Easy-peasy. And any Puppian can do this, whenever they want. The beauty of this is that the user ends up with the very newest, most up-to-date system available at the time they run it...

(shrug...)


Mike.

 

[dos2unix]

Another "gem", Ray!

I can do much worse, trust me.



She Walked In Off the Street
On packages, peril, and knowing when to holster your wget

NOTE: This article contains an elevated level of cheese. The author
recommends a glass of wine before reading. The technical content is
real. Sadie, unfortunately, is also real.

------------------------------------------------------------------------

SHE WALKED IN OFF THE STREET

It was raining. It's always raining in this city, like the sky never
got over something that happened a long time ago and decided the rest
of us should suffer for it. I was in my office, third floor, window
that sticks, radiator that clanks. The kind of office a man rents when
he's good at his work but not good at the other parts.

I was halfway through a cold cup of coffee and a case I should have
walked away from two weeks prior when I heard the knock.

She filled the doorframe the way trouble fills a room -- completely,
and all at once. Built like a brick courthouse. A dress so tight it
had its own legal fees. She had curves that could make a man forget
every good decision he'd ever made, and eyes that suggested she knew
it and had made peace with the fact some time ago.

They called her Sadie.

She had a story, naturally. They always have a story. Hers was smooth
-- too smooth, the way a river stone is smooth, worn down by years of
being handled. She needed help. She was exactly what she appeared to
be. There was nothing to worry about. She just needed a few minutes of
my time.

I told myself I was a professional. I told myself I'd heard worse
lines. I told myself I'd just hear her out.

I should have told myself to go home.

We talked. She was charming, I'll give her that. Knew exactly what to
say and when to say it. By the time I realized I'd been in that chair
for an hour, I was already interested in a way that had nothing to do
with good judgment.

I didn't hear the door open. I never do with Slick Hank -- that's the
thing about him. He doesn't announce himself. He doesn't have to. He
goes where Sadie goes, quiet as smoke, patient as rust.

He was leaning against my filing cabinet, hat tilted, grinning the
grin of a man who already knows how the evening ends. He'd seen this
picture before. He'd been in this office before, more or less, with
more or less the same dame and a different mark in the chair. The mark
who couldn't resist. The mark who just wanted to hear her out.

The mark who never checked who she came in with.

------------------------------------------------------------------------

THE REAL WORLD: CONTROLLED REPOS VS. THE OPEN RANGE

Before we find out how the evening ended, let's talk about where
packages come from -- because Sadie is real, she shows up constantly,
and Slick Hank is almost always behind her.

Official distribution repositories -- Red Hat, Fedora, Debian, Ubuntu,
Mint -- represent a controlled supply chain. Packages are reviewed,
GPG-signed, and maintained by people whose reputations are attached to
the work. When you run "dnf install" or "apt install" against an
official repo, you're trusting a chain of custody that stretches from
the developer to the package maintainer to your machine. That chain
isn't perfect, but it's audited, transparent, and well-traveled.

The grey area: EPEL, Koji, ELRepo, COPR, PPAs, and Snaps

The grey area has a spectrum, and it's worth knowing where things
actually land on it.

Koji is the official Fedora build system -- packages built there are
part of the formal pipeline and carry real accountability. ELRepo is
focused and well-maintained, targeting hardware and kernel drivers for
RHEL-based systems, with a solid track record. RPM Fusion splits
cleanly into free and nonfree sections and has been around long enough
to have earned reasonable trust.

Then there's COPR -- and this is where it gets interesting. COPR is
essentially a public build service where any Fedora account holder can
publish an RPM. The barrier to entry is low by design. Most of what's
there is legitimate: developers publishing bleeding-edge builds,
maintainers bridging the gap before upstream lands in Fedora proper.
But some of it is a stranger's weekend project with no updates since
2021 and no one watching the door. COPR repos aren't reviewed or
vetted by Fedora. When you enable one, you're making a trust decision
about a person, not an institution.

Debian-based systems have their own equivalents. PPAs on Ubuntu follow
the same pattern as COPR but with even less ceremony -- adding one is
essentially granting a stranger's repository permanent write access to
your package list, indefinitely, no expiration, no check-in. You add a
PPA for one package in 2022 and forget about it. Whatever that
maintainer decides to push in 2026 lands on your machine at the next
"apt upgrade".

Canonical's Snap store sits in its own category. The sandboxing story
sounds reassuring until you read the fine print: there is no
meaningful human review. Automated scanning catches some things. It
doesn't catch everything. There is documented history -- not rumor,
not forum paranoia, documented history -- of outright malicious Snaps
sitting in the store long enough to do real damage before anyone
pulled them. A Snap that requests broad permissions at install time
and gets a distracted click-through is not meaningfully sandboxed from
a practical standpoint.

The names change by distro. The question doesn't: who built this, what
is their incentive to get it right, and who is watching if they don't?


Beyond the curated repos entirely

Step outside the repo ecosystem altogether and the landscape opens
further:

- Standalone RPMs and DEBs downloaded directly from project websites
- GitHub release binaries -- built by the project, not reviewed
by anyone else
- Third-party repos added via a one-liner from a blog post or
project install docs
- AppImages and Flatpaks from unverified publishers
- The curl | bash install script -- handing a stranger the keys
and saying "surprise me"

None of these are automatically malicious. Plenty of excellent
software lives exclusively in these channels and serves millions of
users without incident. The point isn't that you should never use
them. The point is that when you step outside the curated repo, you've
taken the vetting job on yourself. You are now the package maintainer.
You are the security review.

------------------------------------------------------------------------

WHAT SLICK HANK ACTUALLY LOOKS LIKE

Slick Hank rarely announces himself. He comes in several forms, and
none of them wear a sign.

The compromised dependency

A package you install has dependencies. Those dependencies have
dependencies. Three layers down, something was quietly updated by
someone who had no business doing so -- a maintainer whose account was
phished, an abandoned project handed to a new owner with different
intentions. The top-level package is fine. What it's pulling in is
not.

The typosquatter

You wanted "libssl-dev". You typed "libssl-dv". The package exists.
It installed cleanly. It does everything it advertised, plus one thing
it didn't mention. Typosquatting is especially common in npm and PyPI
ecosystems, but it surfaces elsewhere too. The name looked right. The
install looked right. The problem won't look like anything until it's
too late.

The slow burn

A project that was perfectly clean eighteen months ago. Actively
maintained, good community, solid reputation. Then the original author
moved on and handed it to someone who offered to help. The new
maintainer made three legitimate improvements, then slipped something
in on a Friday afternoon in a commit buried among seventy other
changes. By the time anyone noticed, it had been in a release for six
weeks.

The innocent-looking install script

The "curl | bash" pattern is so common it's practically expected. Most
of the time it's fine. When it isn't fine, it has root access before
you've finished reading the welcome message. What exactly did that
base64-encoded blob decode to? What's in that /tmp directory it
created and immediately deleted? Did something just write itself to
cron?

------------------------------------------------------------------------

HOW TO CHECK BEFORE YOU DRAW

Read the install script. Actually read it.

Instead of:

curl -fsSL https://example.com/install.sh | bash

Do this:

curl -O https://example.com/install.sh
less install.sh # read it. all of it.
bash install.sh # now run it

If there's a base64-encoded payload in that script, that's a red flag.
If it reaches out to a domain the project has no stated connection to,
ask why. If you genuinely can't tell what it's doing, that's
information.

Verify signatures when they exist

Many projects publish GPG signatures alongside their releases. Use
them. If a project handling sensitive operations doesn't offer them,
that's worth noting. Signature verification isn't paranoia -- it's due
diligence.

Sandbox it before it touches production

Spin up a VM. A container. A spare machine that owes you nothing. Let
the new package run there first. Watch what it does:

ss -tulnp # what ports is it listening on?
systemctl list-units --type=service # did it install a new service?
cat /etc/cron.d/* /etc/crontab # any new scheduled jobs?
find /tmp -newer /tmp -type f # files dropped in /tmp?
journalctl -f # what is it logging?

Watch the wire

New software that immediately makes outbound connections to addresses
you don't recognize is telling you something. Tools like nethogs,
iftop, and ss -tulnp show you who's talking and to whom. Unexpected
egress -- especially to infrastructure in a region the project has no
connection to -- is exactly what you want to catch in a sandbox, not
in production.

Keep your deputies employed

Tools like auditd, rkhunter, and aide exist to notice things you
don't. A package that installs a hidden service, modifies a system
binary, or tampers with your sudo configuration will show up in the
logs -- but only if something is watching. Run these tools. Baseline
your systems. Know what normal looks like so you recognize when it
isn't.

------------------------------------------------------------------------


HIGH NOON -- GIVE OR TAKE A FEW HOURS

I'd seen Sadie's kind before. That's the thing they never count on --
that a man can admire the view and still keep his hand near his
holster.

I'd done my homework before she ever knocked. I knew who she ran with.
I knew what Slick Hank looked like before the hat went on. I knew the
questions to ask and I'd asked every last one of them before I let her
get comfortable in that chair.

When Hank made his move, I was already there.

He walked. He always walks -- there are easier marks in easier
offices, men who ask fewer questions and pour the coffee before
they've checked who's at the door. Sadie went with him. She always
goes with him. That's the part they don't tell you about Sadie -- she
doesn't belong to herself. She never did.

I watched them go from the window, the one that sticks. Lit a
cigarette I don't smoke. Poured the rest of the cold coffee down the
drain.

I was lucky. I was careful. That day, careful was enough.

I turned off the desk lamp. Reached for my hat. It had been a long
Tuesday and I was ready to call it.

That's when I heard the knock.

Different knock. Lighter. Almost apologetic -- the kind that knows
it's late and is asking forgiveness before the door even opens.

I opened it.

She was something else entirely. Red dress. Smile like a secret. Eyes
that hadn't decided yet what kind of trouble they were going to be.
She said her name was Roxanne, and she had a story, and she just
needed a few minutes of my time.

I looked past her into the hallway. Empty. No hat tilted against the
wall, no easy grin. Nobody I recognized.

Not yet.

I told myself I was a professional. I told myself I'd just hear her
out.

I held the door open a little wider.

------------------------------------------------------------------------

THE PART WHERE WE NAME NAMES

Sadie is the package you found at midnight that does exactly what you
needed and has a README so clean it could talk you out of your better
judgment. She lives on GitHub, on project websites, in one-liner
install scripts passed around forums like a business card. She isn't
always dangerous. She's usually fine.

Slick Hank is what followed her in. The malicious dependency buried
three layers down. The cron job that fires at 3 AM. The reverse shell
sitting dormant. The telemetry quietly phoning home to a server you've
never heard of. He counted on one thing to get past your defenses:
that you'd be curious, and that curious would be enough.

The cat, as they say, already knows what killed it.

Official repos exist because someone did the vetting for you. When you
step outside them -- and sometimes you should -- that job is yours
now. Read the script. Watch the wire. Sandbox before production. Keep
your deputies running. Know what normal looks like on your systems so
you recognize the moment it isn't.

You'll still open the door. Any sysadmin who says otherwise is either
lying or boring, and probably both. The goal isn't to stop being
curious.

The goal is to check the hallway before you let her in.

------------------------------------------------------------------------

I told myself I was done with dames. Sadie was gone, the case was
closed, and I was a wiser man for it. I actually believed that for
about five minutes.

That's when Marilyn walked in.

She was something else entirely -- red hair, laugh like a Saturday
afternoon, and a way of looking at a problem that made you feel like
the two of you had figured it out together. She wasn't
dangerous-looking. That was the thing. She just looked like exactly
what you needed, right when you needed it.

It was almost like she knew I had a weakness for funny redheads.

I looked past her into the hallway.

Empty.

I told myself that meant something.

I held the door open a little wider.

 

[ron.alan]

I always update. A very high majority of the time, Linux updates won't break your system, at least not as often as Windows updates the last couple of years has been know for. I have a backup of my system as an .iso file (courtesy of the refracta snapshot tool) just in case an update goes sideways.

 

[Condobloke]

Why does that remind me of 'Joanne' (Michael Nesmith, 1992)

I enjoyed reading that, Ray. very much.

(and yes, I am more than aware of the perils involved in using the 'net, and of the 'promises' of free software etc etc....add infinitum)

 

[osprey]

To Update, or Not to Update — That Is the Question

....

And for you rebels out there — you know who you are — the ones who installed Linux three years ago, updated it once, and have been coasting ever since: part of the reason the real attackers keep finding success is because of systems exactly like yours. Unpatched machines don't just put you at risk, they become footholds, proxies, and pivot points that put the rest of us at risk too. So do the community a favor. Open a terminal. Run your updates. Reboot.

In relation to the question of whether there are statistics on how failure to update a linux system causes some problems, ChatGPT provided the following numbers:

1) General statistics on unpatched systems (applies strongly to Linux)
    60% of breaches involve vulnerabilities with a patch available but not applied
    57% of victims say patching would have prevented the attack
    80% of successful attacks exploit vulnerabilities known for years
 In other words: most real-world compromises aren’t “new bugs”—they’re old, unpatched ones.
Additionally:
    Unpatched vulnerabilities are among the top causes of ransomware infections
    The majority of internet-wide attacks succeed specifically because systems are left unpatched

The references for the general stats appeared to be https://gitnux.org/patch-management-statistics/, but a number of browsers here flashed the site on screen for a fraction of a second and then replaced that by the message: "Application error: a client-side exception has occurred while loading gitnux.org (see the browser console for more information)." so no more info was accessible.

The second reference provided was: https://www.sciencedirect.com/topics/computer-science/unpatched-system, which was accessible.

 

[KGIII]

a number of browsers here flashed the site on screen for a fraction of a second and then replaced that by the message: "Application error: a client-side exception has occurred while loading gitnux.org

Here you go:

Patch Management Statistics: Market Data Report 2026

Unpatched systems cause most data breaches and are extremely costly.

web.archive.org

 

[Condobloke]

Perhaps there are Linux users who do not understand the term 'Patches'

Patches in Linux are updates or snippets of code that fix bugs, address security vulnerabilities, or add new features to software. They are applied to existing software to improve performance and security without needing to replace the entire program.

In other words, patches are a part of the Updating process.

They usually come to the users of Linux, under the umbrella term UPDATES.

 

[garyn]

I liked the "Short Version"

 

[CaffeineAddict]

What I mean is this: the most dangerous thing most home users do on their computer is browse the web. And the browser has become an extraordinarily complex attack surface.

It is true that web based hacks are most popular.
There is an elegant solution a home user can easily use to defend against web browser hacks.

All you need is to use tor browser in virtual machine for all browsing activity.
If system gets compromised it will be localized to guest while your host stays clean, all you need to do is reinstall guest on regular basis to purge anything wrong.

VM setup is the best solution to keep security, because what ever happens it will impact just 1 file on your computer, the VHD.

And tor in addition to VM helps to reduce fingerprinting, and it's friendlier for privacy.
GPU fingerprinting you mentioned is also meaningless in VM because you'll use virtual adapter for display.

This setup doesn't go against your main idea, to update system, ofc. one should update, in VM setup it however needs updating both host and guest, so 1 step more.

 

[nolim]

It is true that web based hacks are most popular.
There is an elegant solution a home user can easily use to defend against web browser hacks.

All you need is to use tor browser in virtual machine for all browsing activity.
If system gets compromised it will be localized to guest while your host stays clean, all you need to do is reinstall guest on regular basis to purge anything wrong.

VM setup is the best solution to keep security, because what ever happens it will impact just 1 file on your computer, the VHD.

And tor in addition to VM helps to reduce fingerprinting, and it's friendlier for privacy.
GPU fingerprinting you mentioned is also meaningless in VM because you'll use virtual adapter for display.

This setup doesn't go against your main idea, to update system, ofc. one should update, in VM setup it however needs updating both host and guest, so 1 step more.

That's why you have flatpak and snap and not only for web browsers. You are running web browser inside a container which is more efficient than a complete VM and provides most of the security isolation and control over the environment.

The drawback, is speed (you are paying something here) and some restrictions on usage which are sometimes good. For example, you can't upload files to your browser from not a specific set of folders in you home directory.

 

[CaffeineAddict]

You are running web browser inside a container which is more efficient than a complete VM and provides most of the security isolation and control over the environment.

I appreciate your input, but this is story for small children.
Your snap and flatpaks are not as secure as full VM.

Here is relevant thread we discussed about this a while ago for more info:

Thread 'flatpak security issues'

Sep 4, 2025

Flatpak Security Flaws: Vulnerabilities in Linux Sandboxing

Flatpak offers Linux users sandboxed apps for security and isolation, but real-world flaws like developer-granted broad permissions, unpatched vulnerabilities, and sandbox escapes undermine its protections. Critics highlight risks of data breaches and misleading claims. Vigilance and community...

www.webpronews.com

Flatpak - a security nightmare

Flatpak - a security nightmare

flatkill.org

• CaffeineAddict
• Replies: 33
• Forum: Linux Security

• 

Same applies to running Windows software in wine, there's another thread about it but it would be off topic.

 

[nolim]

I appreciate your input, but this is story for small children.
Your snap and flatpaks are not as secure as full VM.

That's true. A complete VM is more secure and it runs on a different kernel. However, the issues usually raised against sandboxes and containers are primarily about misconfigured permissions, rather than the technology itself failing.

You can't fairly compare a pre-packaged Flatpak to a VM where you manually configure every strict security rule yourself (and starts with default none). If you were to mount your host's root directory into that VM to make it more convenient, you'd run into the exact same permission vulnerabilities.

It's a tradeoff between security and usability. Do you want your browser to access removable media? Your desktop? Do you want persistent storage and history that you can easily access outside the VM? This is where strict isolation starts to break down. The configuration is usually the issue, not the tools themselves.

 

[CaffeineAddict]

the issues usually raised against sandboxes and containers are primarily about misconfigured permissions, rather than the technology itself failing.

Actually main problem as far as I'm concerned is that sandboxed apps (snaps/flatpaks etc.) don't do reproducible builds.
Without reproducible build you can't be sure the package is originating from safe source.

 

[nolim]

You can also use docker/podman to run for example google chrome/firefox in stateless isolated environment.

This is the docker container (you might choose different distro as well):

FROM  ubuntu:latest
ENV DEBIAN_FRONTEND=noninteractive
ENV DISPLAY=:0
ARG DOCKER_USERNAME=user1
ARG DOCKER_USER_UID=1001

RUN useradd -m -u ${DOCKER_USER_UID} ${DOCKER_USERNAME}

WORKDIR /app

RUN apt-get update && apt-get upgrade -y && apt-get install -y wget

RUN wget https://dl.google.com/linux/direct/google-chrome-stable_current_amd64.deb

RUN apt-get install ./google-chrome-stable_current_amd64.deb -y

USER ${DOCKER_USERNAME}
CMD  "google-chrome"

Code to run it

DOCKER_USER_UID=1001
DOCKER_USERNAME=user1
podman build -t ubuntu_chrome --build-arg="DOCKER_USERNAME=${DOCKER_USERNAME}" --build-arg="DOCKER_USER_UID=${DOCKER_USER_UID}" .

podman run -dit --name container_chrome -e DISPLAY -e XAUTHORITY -v ${XAUTHORITY}:/home/${DOCKER_USERNAME}/.Xauthority -v /tmp/.X11-unix:/tmp/.X11-unix  --replace ubuntu_chrome /bin/bash

xhost +local:
podman exec -it container_chrome google-chrome
xhost -local:

This is much simpler than full VM beast