Jean Louis <bugs@gnu.support> writes:
> * Eric S Fraga <e.fr...@ucl.ac.uk> [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
