Re: Local variables insecurities - Re: One vs many directories
* Detlef Steuer [2020-11-26 14:46]: > Am Thu, 26 Nov 2020 08:31:29 +0300 > schrieb Jean Louis : > > > That is not fair choice. It pushes user to finally ! apply and accept > > it, but does not give chance to permanently ignore it. > > > > > > Do you want to apply it? You can type > > y -- to apply the local variables list. > > n -- to ignore the local variables list. > > ! -- to apply the local variables list, and permanently mark these > > values (*) as safe (in the future, they will be set > > automatically.) > > Well, if you are arguing for a user who chose to use emacs, configured > mutt to invoke emacs etc I do not. Any file opened any how by Emacs is invoking those variables. Please send your opinions to bug: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44837 by writing to: 44...@debbugs.gnu.org > .but at the same time has no idea he chose a > mighty tool, as in has no clue about programming, variables etc., That is right, I have given references. Do not expect users who obtain Emacs editor to be programmers. When user is asked anything, it should be self-documenting and it should have references to that documentation. That is why majority of actions with Emacs do have ? for help at least. Invoking unsafe variables does not even involve any help or references to manual. > then > this choice won't help neither. If you have no idea about local > variables, you can not make an informed decision about *anything* > involving the concept of local variables. Besides stopping and reading > the manual. That is right, but that will be picked by those better positioned few.
Re: Local variables insecurities - Re: One vs many directories
Am Thu, 26 Nov 2020 08:31:29 +0300 schrieb Jean Louis : > That is not fair choice. It pushes user to finally ! apply and accept > it, but does not give chance to permanently ignore it. > > > Do you want to apply it? You can type > y -- to apply the local variables list. > n -- to ignore the local variables list. > ! -- to apply the local variables list, and permanently mark these > values (*) as safe (in the future, they will be set > automatically.) Well, if you are arguing for a user who chose to use emacs, configured mutt to invoke emacs etc, but at the same time has no idea he chose a mighty tool, as in has no clue about programming, variables etc., then this choice won't help neither. If you have no idea about local variables, you can not make an informed decision about *anything* involving the concept of local variables. Besides stopping and reading the manual. May be I miss something, but then I miss it :-) Furthermore this discussion has imho long left the main topic of this list. Detlef
Re: Local variables insecurities - Re: One vs many directories
* Tom Gillespie [2020-11-26 09:19]: > > As there is the option ! to "apply local variables and permanently > > mark these values" but there is no option "not to apply local > > variables and permanently mark these values". > > I have a longer reply that I will send tomorrow, but wanted to respond > to this. > > Yes exactly! I have the equivalent complaint in the draft extras from > my previous message! I actually implemented a blacklist for file local > variables in orgstrap because it is a critical security feature. The > fact that it is missing is absolutely a bug and is extremely annoying > for some of my current workflows where I have local variables that I > never want to accept. Then maybe just add to the same bug your opinion.
Re: Local variables insecurities - Re: One vs many directories
* Greg Minshall [2020-11-26 08:34]: > Tom, > > > 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. > > maybe that is one thing that could really help here. possibly mutt and > other emacs-based mail readers, when putting up a received e-mail > message, should by default do just that (and, also, '(setq > enable-local-variables :safe)'?). > > i use mh-e, and it does *not* seem to do that. but, if emacs is niche, > mh-e is the niche-squared. :) I have sent summary of our discussion here to the bug #44837 for further review, we may switch to better Org related subjects here if you people agree. https://debbugs.gnu.org/cgi/bugreport.cgi?bug=44837
Re: Local variables insecurities - Re: One vs many directories
Located Eric's message and can confirm the same for mu4e (no query about setting/evaluating anything upon opening the message). cm Eric S Fraga writes: > On Wednesday, 25 Nov 2020 at 15:38, Jean Louis wrote: >> I have not configured anything. In fact I have opened the email and I >> was surprised that I am getting those dialogues to execute local >> variables. > > Very strange. It was my email that instigated this part of the > thread. I can view my email and I do not get asked to set any locate > variables or, in this case, evaluate the elisp expression. Out of > curiosity, what mail reader did you use that actually interprets file > local variables? Gnus article view does not.
Re: Local variables insecurities - Re: One vs many directories
> As there is the option ! to "apply local variables and permanently > mark these values" but there is no option "not to apply local > variables and permanently mark these values". I have a longer reply that I will send tomorrow, but wanted to respond to this. Yes exactly! I have the equivalent complaint in the draft extras from my previous message! I actually implemented a blacklist for file local variables in orgstrap because it is a critical security feature. The fact that it is missing is absolutely a bug and is extremely annoying for some of my current workflows where I have local variables that I never want to accept.
Re: Local variables insecurities - Re: One vs many directories
Additionally, as a good example of faulty design, user is coerced to ACCEPT local variables rather than is given fair choice. As there is the option ! to "apply local variables and permanently mark these values" but there is no option "not to apply local variables and permanently mark these values". That is not fair choice. It pushes user to finally ! apply and accept it, but does not give chance to permanently ignore it. Do you want to apply it? You can type y -- to apply the local variables list. n -- to ignore the local variables list. ! -- to apply the local variables list, and permanently mark these values (*) as safe (in the future, they will be set automatically.)
Re: Local variables insecurities - Re: One vs many directories
Tom, > 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. maybe that is one thing that could really help here. possibly mutt and other emacs-based mail readers, when putting up a received e-mail message, should by default do just that (and, also, '(setq enable-local-variables :safe)'?). i use mh-e, and it does *not* seem to do that. but, if emacs is niche, mh-e is the niche-squared. :) cheers, Greg
Re: Local variables insecurities - Re: One vs many directories
* Tom Gillespie [2020-11-26 05:07]: > 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. I know, and do not speak for one person but for those who will not know. To ask users who do not know programming using editor for text editing and to assume that users will know programming terms: variables, values, applying, safe and ANYTHING else that is written in eval: is bad security practice. > 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. Sure, I know, but human text editors will not know. They are faced with YES/NO. What has to be improved is the YES/NO dialogue that has no hyperlinks to its corresponding explanations and asks users things with wrong assumption that user will understand them. > 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. Empowering can take place in the dialogue as such has enhancement space. Do you think it is good idea? > In those cases we also can't assume that the community will be of > much help either, as we are trying to be here. Community is of great help. Users are many and just fraction of users are in this community for example. Only subset of users even while being in community or reading emails or website will be participating in such. > 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. Yes, that is it. To empower user is to give him straight better reference on what to do. Following places could become buttons: The local variables list in new-concept.org ^^^ Button to A below contains values that may not be safe (*). ^^^ Button to A below Button to A below Template: Do you want to apply it? You can type y -- to apply the local variables list. ^^ Button to A below n -- to ignore the local variables list. ! -- to apply the local variables list, and permanently mark these ^^^ Button to A values (*) as safe (in the future, they will be set automatically.) * eval : (let ((pos (org-babel-find-named-block "stages"))) (when pos (save-excursion (org-with-point-at pos (org-babel-execute-src-block) ^^ Button to A below. The template how it looks originally: The local variables list in new-concept.org contains values that may not be safe (*). Do you want to apply it? You can type y -- to apply the local variables list. n -- to ignore the local variables list. ! -- to apply the local variables list, and permanently mark these values (*) as safe (in the future, they will be set automatically.) * eval : (let ((pos (org-babel-find-named-block "stages"))) (when pos (save-excursion (org-with-point-at pos (org-babel-execute-src-block) Button A should follow here: ^ File: emacs.info, Node: Safe File Variables, Prev: Specifying File Variables, Up: File Variables 49.2.4.2 Safety of File Variables . Right now situation is this: - if user press C-g to abort the file will be loaded, which is good - user will not be able to access any of the visible buttons by using cursor because somebody made cursor invisible in that dialogue. Cursor should be made visible that keys can be used to access buttons - There shall be on minibuffer some key like "? TO READ MANUAL" to go straight to the manual section above which is warning user much better. - IF THE USER press C-g, or tries to escape it or clicks by using keyboard on the button, or even switch to the buffer with keyboard, or uses mouse to activate the button, or uses ? to activate to read manual, in all those cases the dialogue should be interrupted and file loaded. User should not be left facing dialogue if it was clear from user's interaction that there was doubt with the meanings of the dialoue. - Adding references on unsafe local variables to TUTORIAL > 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. With such enhancement there is no need to change history of the past, we just change the future and history for the future. > 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
Re: Local variables insecurities - Re: One vs many directories
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)
Re: Local variables insecurities - Re: One vs many directories
* Tim Cross [2020-11-25 23:54]: > I guess this is probably the main point where we disagree. > > Emacs is first and foremost a programmers editor. It was never designed > as a general purpose editor, but rather specifically as an editor for > programmers. Yes. And when I was born as baby I was designed for milk, not for typing, times change. People use GNU/Linux and Emacs is not advertised as programmers or exclusively programmers editor. Some other editors are advertised that way. So think how many hundreds of thousands of users are working with Emacs. Here is how Debian GNU/Linux describes it: https://packages.debian.org/buster/emacs If there are 10 programmers there are probably 100 if not 500 non-programmers. > If you jump into a formula 1 race car, you would find it almost > impossible to drive. The gearbox would be unfamiliar and difficult to > use, the clutch would be difficult to use etc. If you got it going, you > would have a high likelihood of crashing. Luckily, you would probably > just stall and get nowhere. > > Is this the fault of the design of the race car or the driver? Race cars are not distributed through GNU/Linux operating systems and are not easily downloadable by everybody, in general, they are also expensive. While it all sounds entertaining, Emacs is not a race car. And we cannot say to users not to use it if they are not Formula One Drivers. > With respect to your email example, the number of people who are exposed > is even less - it is really only those who are using it in the same > manner as you. That is, where they have configured their mail client > (such as Mutt) to use Emacs as the external editor. None of the Emacs > mail clients I have used do this (this includes VM, mu4e, gnus, > wonderlust and mew). I do not need to use Emacs with Mutt to invoke local variables. I can get files by any means and by any opening of the file with Emacs it will be invoked. Somebody could send me file to download and open. File can come from anywhere, it is not Mutt related really. Gnus buffers and email clients do not invoke local variables and that is fine. But security issue is not email centric, but file centric. > anyone who has gone to the effort to configure their mail system to use > an external editor and who then answers yes to the statement > "...contains values that may not be safe. Do you want to apply it?" is > someone with inherently unsafe practices. That is very rigid assumption. People set editors for various email clients since decades. Try to think from another people's view points. Here is example: https://stackoverflow.com/questions/15865495/opening-a-file-in-emacs-values-that-are-not-safe That person has quite different view point. Person asks "Why it would not be safe?" and one should know when one person writes there for an answer there are probably thousand other persons who did not write for the answer. Other person asked: "Thanks, that's very helpful. Why would a file (i.e. the author of the file) require or ask Emacs to apply configuration values when just opening/visiting the file? – Amelio Vazquez-Reina" I know why, but people using Emacs are asking why. Many will not ask and will say, damn YES, as I feel safe! Denial of Service Attacks possible: https://github.com/aquamacs-emacs/aquamacs-emacs/issues/147 https://gitmemory.com/issue/davidswelt/aquamacs-emacs/147/478196367 .emacs considered not safe: https://www.cs.ait.ac.th/~on/O/oreilly/tcpip/puis/ch11_05.htm OK then now back to Org discussions. Jean
Re: Local variables insecurities - Re: One vs many directories
Jean Louis writes: > * Eric S Fraga [2020-11-25 16:58]: >> On Wednesday, 25 Nov 2020 at 16:13, Jean Louis wrote: >> > I use Mutt. >> > The message is opened in Emacs in mail-mode >> >> Ah, so mutt saves content in a file which is then opened by >> Emacs. Okay, that makes sense. Gnus does things the other way around: >> opens the buffer (associated with a file in the draft directory), >> inserts the content, and then puts the user in control. File local >> variables don't get a chance to be interpreted then. > > That is specific to Gnus. Any file opened by Emacs any will still > invoke the dialogue for local variables. > >> > Then I have been testing and even text files invoke local variables. >> >> Yes, of course. That's the whole point? > > You know that point is bad design and assumption that every user is > programmer who knows what are local variables and what are definitions > of Emacs functions, it is incredible situation. I guess this is probably the main point where we disagree. Emacs is first and foremost a programmers editor. It was never designed as a general purpose editor, but rather specifically as an editor for programmers. If you jump into a formula 1 race car, you would find it almost impossible to drive. The gearbox would be unfamiliar and difficult to use, the clutch would be difficult to use etc. If you got it going, you would have a high likelihood of crashing. Luckily, you would probably just stall and get nowhere. Is this the fault of the design of the race car or the driver? Would it make sense to change the design of a race car to use a standard gearbox and clutch just because at some point someone who is not a race car driver might want to drive it? Are there risks associated with local variables. Yes. Is there sufficient protection against these variables being used for malicious purposes in Emacs. I think the answer is yes. Is there any evidence of these variables being used for malicious purpose. None that I am aware of. Has there been bugs in the implementation of this facility - yes. Have these bugs been addressed once identified - yes. With respect to your email example, the number of people who are exposed is even less - it is really only those who are using it in the same manner as you. That is, where they have configured their mail client (such as Mutt) to use Emacs as the external editor. None of the Emacs mail clients I have used do this (this includes VM, mu4e, gnus, wonderlust and mew). anyone who has gone to the effort to configure their mail system to use an external editor and who then answers yes to the statement "...contains values that may not be safe. Do you want to apply it?" is someone with inherently unsafe practices. I doubt any change in wording or phrasing would be of any help for them. However, the correct way to deal with this would be to offer up a patch to the Emacs developers which improve this wording. I would suggest the set of people who are technically aware enough or have sufficient technical interest to have adopted emacs as their email viewer and who would still answer yes to any dialogue warning them of unsafe actions when opening content from an unknown source is very small. Local variables is a powerful and useful feature. Like many powerful features, it can be abused. We differ in our opinions on whether those safe guards are sufficient. I believe they are and I believe you are over stating the risks. I don't believe we will arrive at any consensus and I feel this thread has run its course. You are of course free to respond, but I will refrain from further participation as this has wondered off topic for org mode and I see little to be gained from further back and forth. -- Tim Cross
Re: Local variables insecurities - Re: One vs many directories
* Eric S Fraga [2020-11-25 16:58]: > On Wednesday, 25 Nov 2020 at 16:13, Jean Louis wrote: > > I use Mutt. > > The message is opened in Emacs in mail-mode > > Ah, so mutt saves content in a file which is then opened by > Emacs. Okay, that makes sense. Gnus does things the other way around: > opens the buffer (associated with a file in the draft directory), > inserts the content, and then puts the user in control. File local > variables don't get a chance to be interpreted then. That is specific to Gnus. Any file opened by Emacs any will still invoke the dialogue for local variables. > > Then I have been testing and even text files invoke local variables. > > Yes, of course. That's the whole point? You know that point is bad design and assumption that every user is programmer who knows what are local variables and what are definitions of Emacs functions, it is incredible situation.
Re: Local variables insecurities - Re: One vs many directories
On Wednesday, 25 Nov 2020 at 16:13, Jean Louis wrote: > I use Mutt. > The message is opened in Emacs in mail-mode Ah, so mutt saves content in a file which is then opened by Emacs. Okay, that makes sense. Gnus does things the other way around: opens the buffer (associated with a file in the draft directory), inserts the content, and then puts the user in control. File local variables don't get a chance to be interpreted then. > Then I have been testing and even text files invoke local variables. Yes, of course. That's the whole point? (and, yes, I've been reading the thread so I know the concerns about security etc.) -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-118-g2a4578.dirty
Re: Local variables insecurities - Re: One vs many directories
* Eric S Fraga [2020-11-25 16:06]: > On Wednesday, 25 Nov 2020 at 15:38, Jean Louis wrote: > > I have not configured anything. In fact I have opened the email and I > > was surprised that I am getting those dialogues to execute local > > variables. > > Very strange. It was my email that instigated this part of the > thread. I can view my email and I do not get asked to set any locate > variables or, in this case, evaluate the elisp expression. Out of > curiosity, what mail reader did you use that actually interprets file > local variables? Gnus article view does not. I use Mutt. The message is opened in Emacs in mail-mode Then I have been testing and even text files invoke local variables. When I send messages I often send it from Emacs, but that is different subject.
Re: Local variables insecurities - Re: One vs many directories
On Wednesday, 25 Nov 2020 at 15:38, Jean Louis wrote: > I have not configured anything. In fact I have opened the email and I > was surprised that I am getting those dialogues to execute local > variables. Very strange. It was my email that instigated this part of the thread. I can view my email and I do not get asked to set any locate variables or, in this case, evaluate the elisp expression. Out of curiosity, what mail reader did you use that actually interprets file local variables? Gnus article view does not. -- : Eric S Fraga via Emacs 28.0.50, Org release_9.4-118-g2a4578.dirty
