Steve PurcellMar 9
First example we at MELPA have seen of an #emacs package getting hacked (upstream of us, in GitHub): https://github.com/kubernetes-el/kubernetes-el/issues/383
This repository has been compromised · Issue #383 · kubernetes-el/kubernetes-el

@noorul 929c639 This repository has been compromised a few days ago. I've just discovered this a few minutes ago. Apparently a Github action was used. I've removed the package from Melpa and blocke...

GitHub
Show threadТеодор Златанов / Ted ZlatanovMar 9
@sanityinc good thread on
this when it was just theoretical https://www.reddit.com/r/emacs/comments/1i1u0rj/how_does_the_emacs_community_protects_itself/?rdt=45984
Show threadSteve PurcellMar 9
@tzz Yeah, many such discussions in the past. IIRC Emacs 31 will have built-in support for diffing package updates before full installation. In this case, the modified file would not have got past the MELPA build step, so we won't have distributed it, but there's no particular barrier to crafting a malicious package that *would* get built.
Show threadSteve PurcellMar 9
@tzz "Maintainer gets compromised" is a very difficult thing to mitigate centrally.
Show threadElias MårtensonMar 9

@sanityinc @tzz And Emacs is by necessity a tool that have wide-ranging access to the system where it's run.

I have been worried about this very thing for a while, in fact every time I install a MELPA package.

Show threadAlex SchroederMar 9
@loke @sanityinc @tzz Same. And what if I'm root? Do I even install packages? I guess I shouldn't. 😬
Show threadHolger
@alex I mostly use jed as root, that's usually good enough for the minor editing needs I have as root. Everything that requires more comfort and capabilities will be done with my normal account and then run as root.
@loke @sanityinc @tzz
Mar 9 at 12:28pmWeb
Show threadElias MårtensonMar 9

@schaueho @alex @sanityinc @tzz I'm not worried about anyone getting access to root. All the sensitive data and actions are available to my regular user, ao that's what I want to protect.

The only approach that works reasonably well today is that of Qubes OS, but it still suffers from the limitation of not exposing any GPU functionality, which is a blocker for many usecases.

Show threadSteve PurcellMar 9
@loke @schaueho @alex @tzz exactly this — my homedir is where the interesting stuff is
Show threadHolgerMar 9

@sanityinc Then the risk of this is not increased (at least not too much) when considering root.

However, given that there are still files that only root can access and things that only root can change on a system, I actually think that usually the risk would be higher for root. But it's not a big point, agreed.
@loke @alex @tzz

Show threadAlex SchroederMar 9
@schaueho @sanityinc @loke @tzz I am worried about rm / in all code. Every time I edit files in /etc I use sudo or root. If Debian packages something I can be reasonably sure that the code is not super malicious. Maybe tracking and telemetry, etc. But anytime I install a bleeding edge thing from npm, PyPI, CPAN, MELPA or whatever to use as root, I start sweating. I try to minimise it and sometimes I forget. asncounter was available from trixie-backports, lucky! I can get rid of this pipx install. Emacs apache-mode or nftables-mode is not packaged by Debian and I only need those for files owned by root. Tricky!
Show threadSteve PurcellMar 9
@alex @schaueho @loke @tzz it's frankly amazing that anything ever works