Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Towards trust in Emacs

eshelyaron.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: Towards trust in Emacs

#31

Post by kode-targz »

jFriedensreich wrote: post #20

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.

Re: Towards trust in Emacs

#32

Post by euroderf »

chocochunks wrote: post #24
TheChaplain wrote: post #11

> ... 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...

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).

Re: Towards trust in Emacs

#33

Post by nacozarina »

quotemstr wrote: post #25
accelbred wrote: post #7

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.

Because the Emacs trust model is incoherent.

now now don’t insult the emacs mafia

Re: Towards trust in Emacs

#34

Post by michaelcampbell »

TheChaplain wrote: post #11

> ... 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...

"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...)

Re: Towards trust in Emacs

#35

Post by kgwxd »

andsoitis wrote: post #10
phplovesong wrote: post #9

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…

Do you not work with others in a code base?

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.

Re: Towards trust in Emacs

#36

Post by quotemstr »

hluska wrote: post #30
quotemstr wrote: post #29

Earlier quoted context omitted.

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
Post reply on HN