[HN Gopher] Towards trust in Emacs
___________________________________________________________________
Towards trust in Emacs
Author : eshelyaron
Score : 175 points
Date : 2026-04-15 13:49 UTC (3 days ago)
(HTM) web link (eshelyaron.com)
(TXT) w3m dump (eshelyaron.com)
| like_any_other wrote:
| 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.
| boxedemp wrote:
| I build my own. Maybe I nee to externalize it...
| nextos wrote:
| 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.
| quotemstr wrote:
| It's exhausting because the model that underpins the whole
| concept is broken
| hluska wrote:
| Everyone got the point the last two times you posted this.
| accelbred wrote:
| 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.
| eshelyaron wrote:
| 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.
| pkal wrote:
| 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)))
| eshelyaron wrote:
| Pretty sure that's unsafe, don't do that.
|
| Only the scratch buffer is to be exempted, not every buffer
| that gets this mode.
| rpdillon wrote:
| Agree. This is probably better: (with-
| current-buffer "*scratch*" (setq-local trusted-
| content :all))
| pkal wrote:
| 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)
| pkal wrote:
| 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*") ...)
| quotemstr wrote:
| Because the Emacs trust model is incoherent.
| quotemstr wrote:
| 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.
| phplovesong wrote:
| 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.
| andsoitis wrote:
| Do you not work with others in a code base?
| phplovesong wrote:
| 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.
| TheChaplain wrote:
| > ... 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...
| JohannesH wrote:
| 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.
| dmd wrote:
| 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."
| chocochunks wrote:
| 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.
| shevy-java wrote:
| "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.)
| jFriedensreich wrote:
| 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.
| kode-targz wrote:
| 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.
| adaptit wrote:
| 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.
| Myrmornis wrote:
| 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 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.
| arikrahman wrote:
| 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?
___________________________________________________________________
(page generated 2026-04-18 23:01 UTC)