From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id wOkYBns4v195EAAA0tVLHw (envelope-from ) for ; Thu, 26 Nov 2020 05:09:15 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id MKvrAXs4v1/dKAAA1q6Kng (envelope-from ) for ; Thu, 26 Nov 2020 05:09:15 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 71B049400D3 for ; Thu, 26 Nov 2020 05:09:14 +0000 (UTC) Received: from localhost ([::1]:41412 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki9Wr-000281-Fi for larch@yhetil.org; Thu, 26 Nov 2020 00:09:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49482) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki9W7-00026G-Ep for emacs-orgmode@gnu.org; Thu, 26 Nov 2020 00:08:27 -0500 Received: from static.rcdrun.com ([95.85.24.50]:49363) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki9W4-0000Ob-RY for emacs-orgmode@gnu.org; Thu, 26 Nov 2020 00:08:27 -0500 Received: from localhost ([::ffff:41.202.241.56]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0010.000000005FBF3825.00001029; Thu, 26 Nov 2020 05:07:49 +0000 Date: Thu, 26 Nov 2020 08:06:36 +0300 From: Jean Louis To: Tom Gillespie Subject: Re: Local variables insecurities - Re: One vs many directories Message-ID: References: <87y2iq6itk.fsf@gmail.com> <87eekhd1sq.fsf@ucl.ac.uk> <87a6v5bkss.fsf@ucl.ac.uk> <87pn416ttu.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Tim Cross , emacs-orgmode Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: inc X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.51 X-TUID: S0jVxxoYhaJf * 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 prompts without reading them, then no one will > take them seriously when they try to argue that it is the prompt > that is insecure. I never say YES by the rule. I have explained sincerely that I did say YES for number of years as I was thinking those are enhancements that make things work. And I have used Emacs in that way for long time. Overall I did not encounter many files with local variables because I did not read other people's files for long time. Please try to get the perspective. I was programming myself but in other languages and never used local variables. If I do not read other people's files it is hard to encounter Local variables. When it came about 2016 to start reading other people's files that is where I rather pressed YES. I did not put attention on each function and those meanings and did not know meanings of functions. If you say that it is important to take users seriously, then take their behavior with the editor seriously and their proneness to failures as well. Do not expect power users. > 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. I think that analogy of Tom with the racing car is better. To make your analogy better it would be like you have the forest with excellent mushrooms and you invite general public to the forest. Then you face public with some of potentially poisonous mushrooms and you start asking them if they wish to accept Amanita muscaria mushroom as it could be possibly unsafe. But people came to see those potentially good mushrooms and did not hear of posionous mushrooms, damn, let me say YES, I am here and I feel safe! > Degrading usability because some users are irresponsible just > reinforces the irresponsible behavior and everyone loses. Usability is already degraded. You can enhance it. It is not nice calling users irresponsible just because they did not read the manual and fully understand it. In addition to Emacs Manual by asking users to decide if variables are safe or not, Emacs is in the same time asking users to know meanings of ALL possible functions and variables that are located in such files. That is one big chunk of assumptions and conditions that user should become responsible by such viewpoint. In that case it would be best to lock the Emacs of using it unless ALL users can pass the test to know everything written in the Emacs manual and Emacs Lisp manual as well. > 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. While that purpose is good and that is same purpose that I am supporting our opinions differ. Do you see how you said: "This provides the user with an opportunity to become aware of a feature of Emacs that is new to them." -- this is what is my wish too. I just think that one cannot become aware of a feature 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. That is optional only in historical terms or if we make time machine to go back and make more future prone defaults. > 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? Button and ? ? was or is at most cases shown to user, but on the dialogue speaking of safety is not shown. > 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 (*)." You could include that for advanced users. The point of discussion is that millions are not advanced users and using terminology such as variable, value, apply, safe is out of the context for the user who is not advanced. Using "pwn" would be hard to understand. When word is out of the context such cannot be understood. I gave one reference from Stack-something where users do not understand "safe" and then other one came with the comment also not understanding "safe". Safe in the context of the dialogue and relation to computing means safe to user's data, privacy and safe computing. One has to know that majority of computer users are not aware of security problems in computing and that they put things on risk. Users who are not programmers or just know how to edit files, translate, make reports, they need not know what is programming and computer terminology. If that would be so than there would be no computing dictionaries, the manual and Emacs Lisp manual just to name few examples. I have my staff members who are using Emacs. They do not know it. One is in Tanzania, one is in Kampala, Uganda. They will know how to edit Org file and how to send me portion of it, but they did not learn nothing about computing. For them the word "safe" is never in the context of computing! Because if one does not know the context around the word meaning is lost. For them "safe" means free from danger or the risk of harm. That is in the personal context, did anybody tell them there is something in the computing context? References from Stack- show example that people understand it so. When saying "safe" one has to say "safe to your data" and if there are no references to context then there shall be references to manual as example. I am not sure if "bold" is right way to warn users if it does not work well on console. Underlined, different colored, links are showing better in console and if somebody does not use colors I think underlined will show better. So if you can do something about that to enhance references to meanings of what dialogue is telling to user, that would be great. Jean