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 aL6zORIOv1/NaAAA0tVLHw (envelope-from ) for ; Thu, 26 Nov 2020 02:08:18 +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 8OyINRIOv1+fJgAA1q6Kng (envelope-from ) for ; Thu, 26 Nov 2020 02:08:18 +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 7DE169401BC for ; Thu, 26 Nov 2020 02:08:18 +0000 (UTC) Received: from localhost ([::1]:53118 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ki6hl-0001mf-H2 for larch@yhetil.org; Wed, 25 Nov 2020 21:08:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36100) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ki6gf-0001NF-Ho for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 21:07:09 -0500 Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:37542) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ki6gd-0002bJ-3b for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 21:07:09 -0500 Received: by mail-wr1-x431.google.com with SMTP id i2so409459wrs.4 for ; Wed, 25 Nov 2020 18:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/gc04B5P+lFzmqiu5kHttvTRJEUFUP3TnSmBpSgiT6M=; b=CNYv8HbQ1C2tRgpfAjqH6vQcZz8sY4U/uA+hU7Pzbzd2u/aXMMSIFFAn4HBgx7zgCh g838R443D2rekyMnfJkkYleWjq/CAXdDW9yLIjT84BTdjE7vd1PdseHsd6M4GqAUEIB0 FFss7fxsxOIS8olsHnHnCBh+NJ/KsXafDlmDWU7cf/TSq4pAUE1Rm6zeQCYBQtgbxg41 zby6Q3eaKE1sk1GhvmMf1GuezVTD1/4V7yRwXkNdSqMKE63GbPv59xIvrPiXRtmTN9Xu TBhEvRB4OBQJevXMNSvQkFFytpXmm7J40v1V02NY6R2zL7kg+JRuBuVO7xu8a3Dbb/s/ LdBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/gc04B5P+lFzmqiu5kHttvTRJEUFUP3TnSmBpSgiT6M=; b=nm5RzHpw6HasQI3DoTI1CL8bly8InAhqFho7pI7ce0L8ZlwPOKXy0Aihq/LZ0lAebe kMH7QzArBd91KIhj+32vGp5/watJ6cCF2F5N9TzEcgkqx9Qt9dBkH0a8mOgvpdw354+u QNdBveis3kRaa2N8tNnpQ4OhGfgXET4BnnQFLtQ5lUYR0Sstm37LvPk+f54uugFtDzCk Baxkap2/BqT3r8yE5WtFnwKH2ClJjsfzdZi/nW8+RpZLOyNkgsBZw0hVXSjy3GtQ7YCK qBNdOEj0Y2wR0cjnNYEeUkr6xulCJUjNrPqkfRLp9AOC6vgYz331HDU0L0QJVugQxUNj 6xLg== X-Gm-Message-State: AOAM533lcUKo/Os4NH+kEJL+WIzoGpEDdfq6Xh1hmkc1odyO6ycVfxKe nv0EXL+9BnCMllXUPty+oMo0d52srmLGsLuRmNI= X-Google-Smtp-Source: ABdhPJxNxgI5roo0Bzj0ptuCijyRMfqbhGT42sMTY+h05rthpJC1HS87FuSHNrXToSeBAty/A3wEV3Ga2joXHPIqRRQ= X-Received: by 2002:a5d:6447:: with SMTP id d7mr855119wrw.96.1606356421577; Wed, 25 Nov 2020 18:07:01 -0800 (PST) MIME-Version: 1.0 References: <87zh36d1xn.fsf@web.de> <87y2iq6itk.fsf@gmail.com> <87eekhd1sq.fsf@ucl.ac.uk> <87a6v5bkss.fsf@ucl.ac.uk> <87pn416ttu.fsf@gmail.com> In-Reply-To: From: Tom Gillespie Date: Wed, 25 Nov 2020 21:06:50 -0500 Message-ID: Subject: Re: Local variables insecurities - Re: One vs many directories To: Jean Louis Content-Type: text/plain; charset="UTF-8" Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=tgbugs@gmail.com; helo=mail-wr1-x431.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=pass header.d=gmail.com header.s=20161025 header.b=CNYv8HbQ; dmarc=pass (policy=none) header.from=gmail.com; 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: -1.71 X-TUID: eTpJvKj0hq1O 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