From: Tom Gillespie <tgbugs@gmail.com> To: Jean Louis <bugs@gnu.support> Cc: Tim Cross <theophilusx@gmail.com>, emacs-orgmode <emacs-orgmode@gnu.org> Subject: Re: Local variables insecurities - Re: One vs many directories Date: Wed, 25 Nov 2020 21:06:50 -0500 Message-ID: <CA+G3_PMh_-a+HtkUQTDmvWv1satUqhx=P6mwMrviDcRR7irqtA@mail.gmail.com> (raw) In-Reply-To: <X77WCeAP00KTdRpE@protected.rcdrun.com> Hi Jean, Some points in summary before a long email. 1. Having an accepting default behavior as a user (i.e., saying yes to all prompts) is bad security practice. The only thing that systems can do is prompt as infrequently as possible in hopes that people don't get prompt fatigue. Emacs does this. 2. If mutt is launching Emacs, you can pass --eval "(setq enable-local-eval nil)" on the command line and all file local variables will be ignored and treated as plain text. 3. If people don't read the manual and don't read the prompt, there isn't much more that Emacs can do while still empowering the user. In those cases we also can't assume that the community will be of much help either, as we are trying to be here. 4. That said, the local variables prompt could be more alarming and provide a quick way to access the manual about local variables. I'll look into a patch for that. Now on to the rest! Full disclosure. I make use of file local variables every day and I have spent quite a while writing orgstrap which relies heavily on them, so I am definitely biased. Emacs is a sharp tool. Experts need sharp tools. If someone complains about the security of prompts but also admits that they always say yes to prompts without reading them, then no one will take them seriously when they try to argue that it is the prompt that is insecure. It is like complaining that the forest is dangerous while insisting on eating the berries of all the plants and picking up all the snakes. The forest is dangerous, but not merely because the berries and the snakes exist in it. Heck, some snakes even try to warn you! There are some rattlesnakes that have evolved to not rattle because idiot humans go find and kill them. Now everyone suffers because there are silent rattlesnakes that will strike without warning. Degrading usability because some users are irresponsible just reinforces the irresponsible behavior and everyone loses. The endgame for all prompts is a two-man two-key system where the switches are separated by 30 feet and must be turned within 1 second of each other. How else could we be sure that the user really meant to say yes!? Emacs is scary, but not nuclear launch system levels of scary. Furthermore, Emacs does try to account for users who don't read the manual and has sane and safe defaults. Namely it does not blindly execute code but prompts the user and lets them know that something is going on. Further, when it prompts the user it does not provide a default action, it forces them to answer so that they must attend to what they are doing. This provides the user with an opportunity to become aware of a feature of Emacs that is new to them. The only other option is to never execute local variables until a user reads the manual and changes their config. Such a design infantilizes the user and does not empower them. Emacs isn't just a dissociated tool, or at least it tries not to be (lots of people also complain about the splash screen being enabled by default!). The Emacs community often also goes out of its way to share its knowledge when such situations arise (as we are doing here). We can't reach everyone (yet!) but many people donate time and effort to share. Emacs and Org both actively encourage users to participate in the mailing lists because venues like StackOverflow are not guaranteed to be seen by the community and are not officially supported. Finally on this point, if we are willing to open the manual we see that Emacs tries to educate users about this, the first line of the section on file local variables is "File-local variables can be dangerous." With regard to the local variables prompt. Maybe the right thing to do in this case would be to add a "?" option so that users can open the manual? That seems like it would help. That said, the second line of the prompt reads "contains variables that may not be safe (*)" which should be alarming. I guess it could be changed to "THIS FILE COULD PWN YOU. Please review potentially unsafe variables marked with an asterisk (*)." Or just make the second line a bold warning? I have a patch I need to send in to make it possible to use lexical scope in eval local variables, I'll take a look at this while I'm there. It is forgivable to not be utterly terrified of systems that can execute arbitrary code, given that they mostly look like rocks, and we are surrounded by them all day. However, they are utterly terrifying existences! While I think it would be great for the Emacs splash screen to come with a big warning that says "WARNING THIS PROGRAM ENABLES YOU TO EXECUTE ARBITRARY CODE" I admit that it took me nearly a decade to begin to understand what arbitrary code execution means and why I should be scared of it. Those words are meaningless to a 12 year old who at best will think "What is the big deal about arbitrary code? I can already run any code that I want!" This is why I pointed you to orgstrap. The eval: (org-sbe startup) local variable is utterly terrifying to me. I added a layer that allows me to know that I have audited the block that I'm about to execute by calculating the checksum of the elisp. Now we have an audited code evaluation system. Much less terrifying, with a chance to prevent nasal demons rather than playing prompt fatigue roulette and hoping it is never my turn. I can't read the instructions for you nor explain better than the link itself https://github.com/tgbugs/orgstrap why you might want to use it if you care about security while still wanting to run code to simplify complex processes. You ask why people need local variables in the first place. The answer is partially because they got sick of getting emails from people who had misconfigured systems and didn't read the manual and the instructions for how to properly configure them to run a file (sound familiar?). They also got sick of people screwing up the indentation of files and not following coding conventions, so they got the computer to do it for them because it is way more effective than trying to do it with politics. People who don't follow instructions don't follow instructions. This seems like an obvious statement, but its consequences are nearly impossible to deal with and there is not much we can do about it other than to reduce the number of instructions we have to give. Local variables are a great way to reduce the number of instructions. I have tested this (unscientifically) and I can report that error rates are lower and users are happier when they can accept local variables and let the author of the file worry about the details. Hard to follow instructions waste everyone's time if they are followed at all. There are better workflows, but they are not foolproof and not obvious. How could they be? Few to none are born knowing cryptography much less the best practices for how to employ it. People put up fences and warning signs, and some folks will still climb over them. I suppose we could go back to only using Turing incomplete systems and languages. Those are probably safe. As alluded to in one of my previous emails, questioning the existence of a feature is often a sign to slow down and take the time to understand what you might be missing. Sometimes there is nothing there, but in Emacs that is rarely the case. To quote myself "Emacs is useful because countless others have encountered problems the likes of which a single person only rarely dreams. Not only that but they have probably already implemented a solution that is fairly easy to find once you encounter the problem and in 80% of the cases can be used unmodified." There are features of Emacs that I suspect I will never know about no matter how long I use it and that is as it should be. There are members of the larger community who I suspect have seen countless users, some new, some veteran, come to question and complain about a feature that they rarely personally use and thus do not understand. Such observers know from experience that there are likely thousands of other users for whom that very feature is a critical part of their daily workflow. Someone posted to this list a few months ago suggesting that org be stripped of all the complexity and broken into smaller projects because they didn't see the need to include things like org-babel in the core. Fortunately the community has long experience with these kinds of limited perspectives and knows how to deal with them, but they cannot simply be ignored. Best, Tom
next prev parent reply other threads:[~2020-11-26 2:08 UTC|newest] Thread overview: 151+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-21 0:33 Texas Cyberthal 2020-11-21 5:13 ` Ihor Radchenko 2020-11-21 7:56 ` Jean Louis 2020-11-21 8:31 ` Texas Cyberthal 2020-11-21 9:29 ` Marvin ‘quintus’ Gülker 2020-11-21 10:21 ` Jean Louis 2020-11-21 15:00 ` Texas Cyberthal 2020-11-21 16:08 ` Jean Louis 2020-11-21 15:03 ` Dr. Arne Babenhauserheide 2020-11-21 15:45 ` Texas Cyberthal 2020-11-21 17:12 ` Jean Louis 2020-11-21 18:01 ` Texas Cyberthal 2020-11-21 18:57 ` Jean Louis 2020-11-22 6:36 ` Ihor Radchenko 2020-11-22 7:20 ` Jean Louis 2020-11-22 8:32 ` Ihor Radchenko 2020-11-22 8:56 ` Jean Louis 2020-11-21 22:36 ` Dr. Arne Babenhauserheide [not found] ` <CAMUm491Psp0u5JKyGROP6M=UfAcvOLTtOKAD1rOearV+KxgYdQ@mail.gmail.com> [not found] ` <87r1olfvh4.fsf@web.de> 2020-11-23 9:50 ` Texas Cyberthal 2020-11-23 13:17 ` Jean Louis 2020-11-23 14:16 ` Ihor Radchenko 2020-11-23 18:08 ` Is Org really so simple? Jean Louis 2020-11-23 20:41 ` Tom Gillespie 2020-11-24 5:06 ` Jean Louis 2020-11-26 3:08 ` Ihor Radchenko 2020-11-26 8:57 ` Jean Louis 2020-11-29 7:20 ` Ihor Radchenko 2020-11-29 16:22 ` Jean Louis 2020-11-26 18:07 ` Dr. Arne Babenhauserheide 2020-11-26 23:09 ` David Rogers 2020-11-27 0:43 ` Tim Cross 2020-11-27 2:56 ` Jean Louis 2020-11-23 16:07 ` One vs many directories Texas Cyberthal 2020-11-23 19:20 ` Jean Louis 2020-11-24 7:55 ` Ihor Radchenko 2020-11-28 16:16 ` Jean Louis 2020-11-28 16:33 ` Christopher Dimech 2020-11-25 6:57 ` Texas Cyberthal 2020-11-25 9:51 ` Jean Louis 2020-11-25 10:39 ` Texas Cyberthal 2020-11-25 11:02 ` Jean Louis 2020-11-26 16:04 ` Texas Cyberthal 2020-11-26 17:31 ` Jean Louis 2020-11-27 9:00 ` Texas Cyberthal 2020-11-27 10:45 ` Jean Louis 2020-11-28 8:18 ` Texas Cyberthal 2020-11-28 10:09 ` Jean Louis 2020-11-29 6:18 ` Texas Cyberthal 2020-11-29 6:53 ` Jean Louis 2020-11-30 7:35 ` Texas Cyberthal 2020-11-30 7:50 ` Ihor Radchenko 2020-11-30 10:25 ` Texas Cyberthal 2020-11-30 10:57 ` Jean Louis 2020-11-30 12:27 ` Ihor Radchenko 2020-11-30 12:28 ` Ihor Radchenko 2020-11-30 19:00 ` Jean Louis 2020-12-02 2:56 ` Ihor Radchenko 2020-12-02 6:14 ` Jean Louis 2020-12-02 7:23 ` Ihor Radchenko 2020-11-21 16:55 ` Jean Louis 2020-11-21 22:48 ` Dr. Arne Babenhauserheide 2020-11-22 0:48 ` Jean Louis 2020-11-22 2:47 ` briangpowell 2020-11-22 17:55 ` Jean Louis 2020-11-21 6:12 ` Palak Mathur 2020-11-21 9:04 ` Jean Louis 2020-11-21 6:36 ` Jean Louis 2020-11-21 7:17 ` Texas Cyberthal 2020-11-21 9:53 ` Jean Louis 2020-11-21 10:15 ` Tim Cross 2020-11-21 11:18 ` Jean Louis 2020-11-21 14:44 ` Texas Cyberthal 2020-11-21 15:45 ` Jean Louis 2020-11-23 5:40 ` Ihor Radchenko 2020-11-24 9:00 ` Jean Louis 2020-11-24 9:45 ` Eric S Fraga 2020-11-24 9:51 ` Jean Louis 2020-11-24 11:42 ` Eric S Fraga 2020-11-24 13:13 ` Diego Zamboni 2020-11-24 13:49 ` Jean Louis 2020-11-24 17:02 ` Jean Louis 2020-11-24 18:50 ` Dr. Arne Babenhauserheide 2020-11-24 18:58 ` Jean Louis 2020-11-25 6:39 ` Tim Cross 2020-11-25 12:38 ` Local variables insecurities - " Jean Louis 2020-11-25 13:05 ` Eric S Fraga 2020-11-25 13:13 ` Jean Louis 2020-11-25 13:58 ` Eric S Fraga 2020-11-25 14:07 ` Jean Louis 2020-11-25 20:54 ` Tim Cross 2020-11-25 22:09 ` Jean Louis 2020-11-26 2:06 ` Tom Gillespie [this message] 2020-11-26 5:06 ` Jean Louis 2020-11-26 5:31 ` Jean Louis 2020-11-26 6:18 ` Tom Gillespie 2020-11-26 9:10 ` Jean Louis 2020-11-26 11:44 ` Detlef Steuer 2020-11-26 12:06 ` Jean Louis 2020-11-26 5:34 ` Greg Minshall 2020-11-26 5:49 ` Jean Louis 2020-11-26 8:39 ` Christian Moe 2020-11-25 8:10 ` Dr. Arne Babenhauserheide 2020-11-25 8:36 ` Local variables liberties Jean Louis 2020-11-24 20:11 ` One vs many directories Tom Gillespie 2020-11-24 20:39 ` Tim Cross 2020-11-25 4:54 ` Jean Louis 2020-11-25 5:54 ` Tim Cross 2020-11-25 7:01 ` Local variables issue - " Jean Louis 2020-11-25 5:06 ` Jean Louis 2020-11-25 7:00 ` Tim Cross 2020-11-25 8:23 ` Security issues in Emacs packages Jean Louis 2020-11-25 9:07 ` tomas 2020-11-25 9:26 ` Jean Louis 2020-11-25 10:41 ` tomas 2020-11-25 22:46 ` Tim Cross 2020-11-25 23:07 ` Jean Louis 2020-11-25 23:39 ` Tim Cross 2020-11-26 5:24 ` Jean Louis 2020-11-26 6:46 ` Tim Cross 2020-11-26 5:29 ` Greg Minshall 2020-11-26 5:53 ` Jean Louis 2020-11-26 6:35 ` Tim Cross 2020-11-26 12:27 ` Greg Minshall 2020-11-26 22:20 ` Tim Cross 2020-11-27 2:19 ` Jean Louis 2020-11-27 4:42 ` Greg Minshall 2020-11-25 4:44 ` One vs many directories Jean Louis 2020-11-25 10:19 ` org-sbe to automate some source block executions Jean Louis 2020-11-25 11:39 ` Ihor Radchenko 2020-11-25 15:06 ` Jean Louis 2020-11-25 11:46 ` One vs many directories Jean Louis 2020-11-25 13:07 ` Eric S Fraga 2020-11-25 13:14 ` Jean Louis 2020-11-25 13:12 ` Ihor Radchenko 2020-11-25 13:32 ` Jean Louis 2020-11-24 18:47 ` Dr. Arne Babenhauserheide 2020-11-24 18:54 ` Jean Louis 2020-11-25 8:14 ` Dr. Arne Babenhauserheide 2020-11-25 8:46 ` Jean Louis 2020-11-25 11:46 ` Ihor Radchenko 2020-11-26 12:47 ` Jean Louis 2020-11-26 13:27 ` Ihor Radchenko 2020-12-02 10:12 ` Jean Louis 2020-12-02 9:49 ` Jean Louis 2020-11-26 3:47 ` Ihor Radchenko 2020-11-26 3:32 ` Ihor Radchenko 2020-11-26 11:58 ` Jean Louis 2020-11-29 7:56 ` Ihor Radchenko 2020-11-29 17:57 ` Jean Louis 2020-11-21 13:41 ` Jonathan McHugh 2020-11-21 14:04 ` Jean Louis
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://orgmode.org * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CA+G3_PMh_-a+HtkUQTDmvWv1satUqhx=P6mwMrviDcRR7irqtA@mail.gmail.com' \ --to=tgbugs@gmail.com \ --cc=bugs@gnu.support \ --cc=emacs-orgmode@gnu.org \ --cc=theophilusx@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ emacs-orgmode@gnu.org public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git