Towards trust in Emacs | Hacker News Reader

Towards trust in Emacs

eshelyaron.com

189 pointseshelyaron32 comments

> ... the problem with security measures that cause too much friction is that users tend to disable them in order to get on with their work. To fulfill its security purposes, a good trust system needs to stay out of your way.

I wish this was understood clearly by more security engineers, but, alas...

At my work when our IT sec org tighten the screws harder and harder, people just have to get "creative" to do their job effectively. For us this meant that some of my coworkers started using their own machines to write code making the whole setup much more unsafe and prone to breaches.

But I definitely feel there's a huge missing part in our setup and lack of accountability in the It sec org when it comes to not hurting productivity unnecessarily. They can just keep putting up barriers without any real consideration to the impact and side effects they may have.

It’s blame shifting. If the security people are allowed to make it impossible to work without breaking the rules, they’ve successfully moved all blame for anything that goes wrong away from themselves. “Oh, you turned your computer on? Well, the security guidelines clearly state that’s not allowed, so that’s your fault.”

"If you're able to do your job, InfoSec isn't doing theirs."

I've worked with some great sec orgs that get this and I'm sure everyone reading this in that role is one of those, but understand there are some that are not.

There are some who, for example, are not given ANY agency whatsoever and have to accept every alert from tool-du-jour as some malicious moustache-twirling evilness from the developer. (And they AI should be taking over _development_ jobs...)

This is how I felt about macOS for my workflow. It was like living in a house where every room autolocks every time you leave the room, great for security but horrible if you need to move from room to room constantly.

Well, but if there's a chance of random attackers walking around your house then the autolocking kinda makes sense (assuming a realistic timeout on it).

The article is still missing the most important point about a "trust system" -- you have to explain what it is and convince me that I even care about the problem you're trying to solve. It's my machine, what is a "trusted" or "untrusted" file? If people just force security "solutions" on me without asking me whether I understand or agree with their problem diagnosis then I will immediately disable the protection if I can or blanket accept all prompts without thinking.

This is good, but it doesn't go far enough:

The one problem I have with the trusted files thing is that I have no way to trust non-file-visiting buffers. Why is *scratch* untrusted!? *scratch* should always be trusted, without me having to configure anything, ideally. Though a setting to automatically trust non-file-visiting buffers would be nice. I just ended up stopping using the scratch buffer because of that issue.

Right, the fact that the initial scratch buffer is untrusted is a bug AFAICT. I'm considering adding a workaround to this issue in trust-manager, although ideally it should (also) be solved upstream.

Shouldn't something like this fix the problem, at least for scratch buffers:

(add-hook 'lisp-interaction-mode-hook (lambda () (setq-local trusted-content :all)))

Pretty sure that's unsafe, don't do that.

Only the scratch buffer is to be exempted, not every buffer that gets this mode.

Do note that I only configure this for `lisp-interaction-mode', which in practice really only gets used for the *scratch* buffer. But there are a few other instances in core that also use it, and if that concerns you, you can extend the above snippet with a check like

    (when (equal (buffer-name) "*scratch*") ...)

Agree. This is probably better:

    (with-current-buffer "*scratch*"
  (setq-local trusted-content :all))

In practice this should also work. Do keep in mind if you just add this to your init.el then this will not persist if you re-create the scratch buffer.

If we are already experimenting with different ideas, this should also work (and gives a hint of how you want to fix the issue upstream):

    (define-advice get-scratch-buffer-create (:filter-return (buf) trusted)
      (with-current-buffer buf
        (setq-local trusted-content :all))
      buf)

Because the Emacs trust model is incoherent.

now now don’t insult the emacs mafia

I would say the trust model of all editors is broken. You cannot really blanket trust any project at all with agents and the amount of supplychain attacks, not even your own. Editors must move to a capabilty based sandbox where you dont just grant trust but grant concrete capabilities like in a browser sandbox.

i don't think the core problem here has anything to do with trust to be honest. The problem here os developers using so many external packages and code and libraries for their projects; commercial or otherwise. them just having to ho on trusting everything by default is just one of the many side effects of that.

The trust model of Emacs makes no sense. It's overly conservative, hurts the development experience, encourages blanket permission granting, and worst of all, sins against logic and lisp themselves.

Macro expansion is data transformation. Form in, form out. Most macros are pure functions of their inputs. Even the ones that aren't seldom have effects that would allow exploitation. That's because a well-written macro does not have side-effects during expansion time, but instead generates code that when itself evaluated, has the desired effect.

Yes, in general, for arbitrary values of "macro" and "form", using a macro to expand a form leads to arbitrary code execution. This much is true. But the risk only manifests when both the macro and its input form are untrusted.

The vast majority of macros are dumb pure functions and do not perform dangerous actions on untrusted input. It is safe to use these macros to expand untrusted forms. Doing os would make flymake, find-function, and other features work correctly in most cases. To blanket-prohibit expansion even by macros doing obviously safe transformations is to misunderstand the issue.

At a minimum, it must be possible to define a macro and mark it safe for expanding untrusted code. Yes, it's prudent to have a whitelist and not a blacklist. Right now, we don't even have a whitelist. All macros on any untrusted form are deemed unsafe. That's too conservative.

Beyond that, it would be safe to run the macro-expander itself in an environment without access to mutating global operations. Since almost all macros are intrinsically safe to expand, we'd have far fewer situations in which people had subpar development experiences from overly conservative security mitigations.

In addition, after I've eval-buffered a buffer, then Emacs should perform macro expansions in this buffer, at least until I revert it from disk. If I have evaled a malicous buffer, I have already accepted its malice into my Emacs and expanding macros for find-function can do no more harm.

I'm a newb to Emacs, I've been using unstraightened Doom Emacs and have never been prompted to trust a project I've opened. Should I be worried?

It's getting so very old - all I want out of a process is code autocomplete, but I have to grant it read & write permission to my entire disk and network. When do we get good permissions and sandboxing and isolation? This can't go on.

I agree granting processes permission to read any file is unsustainable.

In Linux, sandboxing with Firejail or bwrap is quite easy to configure and allows fine-grained permissions.

Also, the new Landlock LSM and LSM-eBPF are quite promising.

I build my own. Maybe I nee to externalize it...

It's exhausting because the model that underpins the whole concept is broken

Everyone got the point the last two times you posted this.

Then perhaps people should engage with the technical substance of something once in a while

"Up to version 30, it didn’t differentiate between trusted and untrusted files, and in effect treated all files as trusted."

Age verification aaaaaand Trusted Computing now! \o/

(Just kidding - have to point at the question of what trust is exactly. Because I can not accept the "trusted files" claim; I don't think anyone can ever trust anything, unless there is some really objective criterium that is unchangeable. But if something is unchangeable, can it be useful for anything? Yes, you can ensure that a calculator would correctly put a given input into the correct output, or a function to do so, but in real calculation this is not the only factor to be guaranteed, not even in quantum computing. What if you manage to influence the calculation process via light/laser information or any other means? I can't accept the term "trusted" here, because it implies one could and should trust something; that is a similar problem to the term AI - I never could accept that "AI" has anything to do with real intelligence with the given hardware, it is just a simulation of intelligence; pattern matching and recognition only makes it more likely to produce useful results, but that does not imply intelligence at all. It lack true understanding - that is why it has to sniff for data, to improve the mapping of generated output. One can see this on many AI-centric videos on youtube, the AI is often hallucinating and creating videos that are not possible, e. g. suddenly a leg appearing in motion that is twisted in the opposite direction. That shows that the AI does not understand what it is doing. Any human could realise that this is physically just not possible. I see this on cheaper AI videos even more, e. g. chuck norris videos where chuck would kick everyone yet the motions are totally wrong and detached from the "real" scene.)

Emacs is powerful, but the complexity overhead of managing a custom trust layer could easily become a major maintenance bottleneck for average users. Worth considering, but the friction point is significant.

I tried AI, and i never could/dared to actually push anything to prod. The code seems ok, but i always have a gut feeling somethings off.

I guess the most valuable thing you loose is the "what" and "how". You cant learn these things from just reading code, because the mental model just is not there.

Also i dislike code reviews, it feels "like a waste of time" because sure i can spot some things, but i never can give the real feedback, because the mental model is not there (i did not write this code).

Having said that, I still use AI for my own code review, AI can spot some one-offs, typos, or even a few edge cases i missed.

But i still write my own code, i want to own it, i want to have an intimate knowledge of it and really understand the whys and whats.

Do you not work with others in a code base?

I do, but in this case some one else did the writing, not AI. I can always drop them a PM about how/why something is like it is. I cant do this with AI, and when trying you cant trust the real reason, and the answer will pretty much change depending on how you ask it.

Yeah, and it's awful working with someone you know is going to mess thing up, in major ways, has no self-reflection, and cannot be held accountable for anything, because they're management's best buddy.

Reply on news.ycombinator.com