
ShrekOS field notes · August 2026
I have no idea what I'm f*cking doing. Something I learned today:
"Install one tool" is a lie I keep telling myself to feel safe.
I wanted a tool on my machine. ffmpeg. So I ran apt install ffmpeg without thinking twice. It feels like one small, clean action. You type a command, you press enter, you wait for the green checkmark. You think you have added a binary. You are wrong.
It is not one action. A .deb package can carry maintainer scripts, preinst and postinst, and dpkg runs those scripts as root during the install. That is arbitrary code from the package, executing as root, as a normal part of "installing."
I have done this for years. I trust apt. I trust the repositories. I am a professional. I should have known better.
It also updates the package database under /var/lib/dpkg, runs ldconfig, rewrites alternatives symlinks, drops configuration files into /etc, and fires triggers that touch other packages. Every dependency it pulls in does the same thing.
So "install one tool" actually means: run someone else's scripts as root, and scatter state I did not audit across my system, multiplied by every dependency in the chain.
None of it is sandboxed. All of it is trusted, because that is how host package installation works. I am trusting the repo, the maintainer, and every script, with root, every time.
🧅 peel the jargonIn plain terms. When you "install" something on Linux, you are not just copying a program in. The package is allowed to run its own setup scripts as the most powerful user on the machine, and those scripts can touch anything. You are trusting whoever built that package, and everyone whose code it depends on, with the keys to the house. Usually that trust is fine. The point is that it IS trust, every single time.
When an AI agent decides it needs ffmpeg and emits apt install ffmpeg, the command is correct. The model did its job. The uncomfortable part is that on an ordinary machine, "install" means handing root to a pile of scripts nobody read. Whether that command should be allowed to rewrite my system is not the model's call to make. It is mine, and I had been making it by reflex.
I used to think the danger was in malicious packages. Now I see the danger is in the normal ones. The normal ones are worse, because you stop looking.
Before you let anything, an agent or yourself, "just install it," be honest that install means arbitrary root code plus state you do not control, times every dependency. On a machine you actually care about, that authority should be a decision, not a default.
🧪 What I actually tested⚠️ Where I might be wrongWhat I ran. Want to see it without installing anything?
apt-get install --download-only <pkg>grabs the .deb, thendpkg-deb -e <file>.deb /tmp/scriptsextracts its control scripts. Read the postinst. That is code that would have run as root on your machine. After a real install,dpkg -L <pkg>lists every path it touched.
The honest caveat. Most packages are boring and safe, and the Debian repos are curated, so this is not "apt is evil." The point is the shape of the authority, not that any given package abuses it. Other systems differ in the details (rpm, apk and friends run their own install scriptlets), but the principle holds everywhere: install means running trusted code as root, plus state you did not audit.
This article was originally published by DEV Community and written by Constant Itis.
Read original article on DEV Community