Post 9nfLPdZpf8WdlsuGoa by half_cambodian_hacker_man@mastodon.technology
 (DIR) More posts by half_cambodian_hacker_man@mastodon.technology
 (DIR) Post #9nfJoaTrAEz7Vbc2Ma by codesections@fosstodon.org
       2019-10-07T00:30:26Z
       
       0 likes, 0 repeats
       
       > Ooof, time to be more secure, Emacs... https://illikainen.dev/blog/2019-10-06-editorconfigThis seems…actually not all that bad?  If I'm reading this correctly, all it seems to be saying is that #emacs is vulnerable to supply-chain attacks—of exactly the same sort that #npm, or #cargo, or any other package repository is vulnerable.If you execute code on your computer and that code is malicious, you're going to have a bad day, no matter the source.Or am I missing something?
       
 (DIR) Post #9nfLPdZpf8WdlsuGoa by half_cambodian_hacker_man@mastodon.technology
       2019-10-07T00:48:24Z
       
       0 likes, 0 repeats
       
       @codesections This is remote code execution via a simple `git clone <url>; emacs project/src/file.whatever`
       
 (DIR) Post #9nfNoIS3XjsxOr9hpo by codesections@fosstodon.org
       2019-10-07T01:15:19Z
       
       0 likes, 0 repeats
       
       @half_cambodian_hacker_man > This is remote code execution via a simple `git clone <url>; emacs project/src/file.whatever`But isn't that only if the user has downloaded a malicious `.editorconfig` file?
       
 (DIR) Post #9nftoL9AiclOIDO46i by realTimo@mastodon.social
       2019-10-07T07:13:45Z
       
       0 likes, 0 repeats
       
       @codesections From what I gather, there's no need to obfuscate lisp code in a C source file when the problem affects lisp users with a - so it seems - fairly standard config anyway.If you wanted to vet lisp code you downloaded with emacs, you'd run into the issue anyway.I disagree, though, that this is a standard supply chain attack vector like in npm or cargo. You never meant to *execute* the code your're vetting.I am more puzzled by this readily available eval-and-compile macro.