First (?) hacked Emacs package
26 points by kana
26 points by kana
I'm increasingly worried about becoming a victim of these kinds of supply chain attacks. By choice, I don't use any exotic software and, as such, my system is pretty code to a standard Fedora install, plus a few Vim packages, scientific python libraries and some other stuff that, that just doesn't come to my mind right now. Regardless, I know that when I do install new software, I never check if the Github config is trustworthy or what the transitive dependencies are. It's impossible to individually guard against supply chain attacks; it takes too much time and requires too much expertise.
My best guess for a short-term solution is to stop installing the newest releases. It seems like these kinds of attacks are usually caught within a few weeks or months at maximum. Not installing new releases for a bit means that I also don't get new security patches, but I suspect that, on average, this isn't such a big deal when we're talking about mature software.
Several years ago I switched my own emacs config over to using git subtrees to pull in packages instead of using the built-in package.el: https://git.sr.ht/~technomancy/dotfiles/tree/main/item/.emacs.d/lib
It means that adding a new package is more work, but I don't see that as being strictly a bad thing. Before I add a new one, I read thru the entire thing. This means I don't add that many, and I never add any that have complex dependency trees. But guess what; I can still use Emacs effectively!
Automated package managers are great at hiding the true cost of code from you.
I just found out today from a link in the orange site's coverage of this that package.el has a package-review-policy option that can be used to implement a workflow similar to your own.
Yeah, I was using a similar setup. An added benefit is that one can just git clone the whole ~/.emacs.d and get a working emacs without connecting to (m)elpa.
I've been meaning to move from emacs package managers to a script that I own for downloading git repos and pinning versions for years... now this will probably give me the motivation to do that.
straight.el and Nix are both really good at this! My config has every elisp package pinned and Nix builds a full closure by pulling latest Emacs + pinned packages. Best part is, I can take the same flake.nix to new computer and buuld the exact same closure there within few minutes!
FWIW doom-emacs also pins all the deps, I doubt they extensively review every update to every dep, and because there are a lot of modules, it also has a lot of dependencies, so kinda anti-point.
I love Nix/NixOS and use it on all of my personal machines aside from phones and tablets (unfortunately, since they lack proper UEFI/ACPI)! But emacs is actually the last thing I'm interested in nix-ifying. I need to use my emacs config on weird machines that I don't own, in docker containers that I am handed, on operating systems that my employer may dictate, etc.
I do use straight.el, but I actually don't love its pinning feature, so I've been thinking about replacing it, and probably paring down the number of packages I use while doing so. But maybe I've just been “holding it wrong”. I'll review it before I do anything drastic.
I just have ~/.emacs.d in one git repo, so I don't have to deal with subtrees =P
It works very well. So simple to revert if there's a regression or something. I wish I did it 20 years ago instead of only 5 years ago :)
I think you might be getting this mixed up with submodules; subtrees allow you to keep them in one repo; it just stores metadata describing the source repo for future updates. While I'm not sure that overall I would recommend them over submodules, they're better-suited for this case.