Hacker Newsnew | past | comments | ask | show | jobs | submit | snarf_br's commentslogin

No it does not. It depends on what the market is willing to pay.


It’s actually both.


No


Overhyped, misnomer as this is not an RCE, and emacs maintainers who are correct as you can trigger the same thing by just running git ls-files to execute things if you configure the .git folder as the exploit does.


Disclosure: I didn’t discover the bugs, but helped write the blog post.

These issues are technically classified as local code execution (AV:L), but they go against a pretty strong user expectation: that opening a file should be safe. In reality, they can be triggered through very common workflows like downloading and opening files, which makes them feel a lot closer to some remote scenarios, even if they’re not strictly RCE.

At the end of the day, regardless of how you classify them, it’s worth being aware of the risks when opening untrusted files in editors like Vim or Emacs.


That is not an RCE. That is an RTFM and you need to learn that you don't download stuff you don't know about


I'm pretty sure the lesson is that at the end of the day, it’s worth being aware of the risks of using git, as security issues intrinsic to git can extend to other tools which use git as a component.


I think we can agree that Git is at least partly responsible for this issue, if not more.

That said, even being aware of that doesn’t necessarily help much in practice. When you’re using Emacs or Vim, you’re not really thinking about Git at all. You’re just opening and editing files. So it’s not obvious to most users why Git would be relevant in that context.

This is why I think editor maintainers should do more to protect their users. Even if the root cause sits elsewhere, users experience the risk at the point where they open files. From their perspective, the editor is the last line of defense, so it makes sense to add safeguards there.


Please read the LLM output critically instead of doubling down on it.

Your defense-in-depth framing makes no sense. If .git/config or similar mechanisms are the attack vector, then adding more editor safeguards would be treating a symptom, as the real problem is git's trust model. The "users don't think about git when using editors" argument also proves too much. Many users also do not think about PATH, shell configs, dynamic linker, or their font renderer either, but you cannot make editors bulletproof against all transitive dependencies...

Seriously, it is actually backwards. Git is where the defense belongs, not every downstream tool that happens to invoke git. Asking editors to sandbox git's behavior is exactly as absurd as it sounds.

And BTW, "technically AV:L but feels like RCE" is your usual blog-post hype. It either is, or is not.


Sure, but you said that was the end of the day analysis, and I didn't think you went far enough in your analysis.

FWIW, I'm not thinking about git at all since I use Mercurial, and never enabled vc hooks in my emacs, which is based on 25.3.50.1, so wasn't affected by this exploit - I tested. I use git and hg only from the command-line.

My end-of-day analysis is to avoid git entirely if you can't trust its security model. ;)

Should the emacs developers also do more to secure emacs against ImageMagick exploits?


Git is also not responsible. Please stop drinking this LLM coolaid and trying to get hype on that.


Remote Code Execution, which this isn't, in both cases.

It is code execution.


Nonsense


It's a distraction.


Factually and environmentally as well.


I guess all the publishers and advertisers are worried and complaining about nothing


Sounds very cultish..


It is! If your life is in shambles because you're suffering from alcoholism and you don't want it to be anymore, join the cult who's only requirement is a desire to quit drinking. There's no kool-aid laced with poison in a sucide death pact going on, just a desire to help people live better lives.


I disagree, on both levels.

The application is perfectly fine for my needs and I'm ok with the ui.

But if you want something else, you can change that.

So grab the source code, try to get it to compile and run, and start making changes.

You have the freedom to do so. Use it. It doesn't matter that you're not great. Just do. No need to wait for others.


As an avid GIMPer for ~12 years now, I hate the UI. It's only fine because I've struggled through it for so long and now I know where and how things are.

But it's really poorly designed and outdated. I completely understand and sympathize with anyone trying to use GIMP for the first time.


Correct, I prefer inkscape and inkpot projects. Don’t use gimp.


Honestly, I don't see where it violates that code of conduct.

Luckily, no one cares about my (or your) opinions on that matter because, as far as I can tell, neither of us have contributed anything to Zig.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: