From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id oJWECZH8vV8vUwAA0tVLHw (envelope-from ) for ; Wed, 25 Nov 2020 06:41:21 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id YBltBZH8vV+kRgAAB5/wlQ (envelope-from ) for ; Wed, 25 Nov 2020 06:41:21 +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 7F12A9403E8 for ; Wed, 25 Nov 2020 06:41:19 +0000 (UTC) Received: from localhost ([::1]:37854 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1khoUP-0005Uq-6B for larch@yhetil.org; Wed, 25 Nov 2020 01:41:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38116) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1khoTC-0005UY-JO for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 01:40:02 -0500 Received: from mail-pf1-x42f.google.com ([2607:f8b0:4864:20::42f]:39349) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1khoT7-0002p7-VT for emacs-orgmode@gnu.org; Wed, 25 Nov 2020 01:40:02 -0500 Received: by mail-pf1-x42f.google.com with SMTP id x24so1393085pfn.6 for ; Tue, 24 Nov 2020 22:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=references:user-agent:from:to:subject:in-reply-to:message-id:date :mime-version:content-transfer-encoding; bh=ptsztX3EZQH/5QQmEG4T++O1R+JjZNLg3TEADD+/nsw=; b=LoXUqM9FlV/Q4Fkw9O9fXt+UQkHoZki4yTTrzwO73g1F9EizZEDafkI6z7mL91cyB6 cB6rjNKj1bQic5Ukd2Bh6Ln+uKvoc1f8kv7Yt+OPqMGLdz5P1n2PfmibN73vec9T0QZy ZCdFKETUyskPTCGut4YqCw0kDYinWCxo0KiTL4fopqKwwO0YXhhv9/GpmtQeP5/a23yi bRxVEgmlyC99/3Nzyhz8cGEfDAKgLR2nCZ3/mPwAnO+V6uzZcUjlxS3qLZcJBI5R/GLZ 8CQ2QOo49S7d9JlhzAcxe50PKlUh6SBLZ1KLqlpRCrH8Bkq/CddshTdqcd5uTHD8y3Uv iyMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:subject :in-reply-to:message-id:date:mime-version:content-transfer-encoding; bh=ptsztX3EZQH/5QQmEG4T++O1R+JjZNLg3TEADD+/nsw=; b=QAs4PUeMoY10UrgV9RjFjyWoIeyRO4a6/SRYPDAP7DCW0LeE414nYKwFxEk4e75UGh 7Br4KHww5FDe6b715sZ4uJeihrMBXEMjirhWug9HdSt1TZbCneNZ5M9RIMLk/7swKP9L pCWpfB3LkMF3cTOySsUeRdtk6bGH5mm85CyaQkw5vlmqUlOANryA2ujGs2IxZfn/JXsy oU9inRIRzuPqSFoBkL4KVADhCUCMaQGsOrcNUPoB6OIDLN6VrnWK2H0XN75HkH9LiIyF WrjF/0spBQMa8mykAcTQQJEjFk9O6dnCLaMZTCPkWf/aDov3pqTKoMNrWBSmZBUGriHg ZzIg== X-Gm-Message-State: AOAM531OSSUnKUp5Jb8he1i8azGiwj3nwkRjGrn95N4v40E0KlzsuxY0 mgYCzULA3mE7+vu3VZErycji5X51EdocCQ== X-Google-Smtp-Source: ABdhPJzNBEoiQpFrFAtyOjkoLmtLwI0yCAAge1p40vkH62K18VARqE2r4vSvgA52CaJV/RvgjdGdFQ== X-Received: by 2002:a63:f54c:: with SMTP id e12mr1870371pgk.415.1606286395118; Tue, 24 Nov 2020 22:39:55 -0800 (PST) Received: from tim-desktop (220-235-2-238.dyn.iinet.net.au. [220.235.2.238]) by smtp.gmail.com with ESMTPSA id o18sm932172pfp.16.2020.11.24.22.39.53 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Nov 2020 22:39:54 -0800 (PST) References: <87mtz84om9.fsf@localhost> <87ft4zhyuo.fsf@disroot.org> <877dqbhtgf.fsf@ucl.ac.uk> <87zh36d1xn.fsf@web.de> User-agent: mu4e 1.5.7; emacs 27.1.50 From: Tim Cross To: emacs-orgmode@gnu.org Subject: Re: One vs many directories In-reply-to: Message-ID: <87y2iq6itk.fsf@gmail.com> Date: Wed, 25 Nov 2020 17:39:51 +1100 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2607:f8b0:4864:20::42f; envelope-from=theophilusx@gmail.com; helo=mail-pf1-x42f.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, T_FILL_THIS_FORM_SHORT=0.01 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: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20161025 header.b=LoXUqM9F; 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: TIFOsaZKKfEJ Jean Louis writes: > * Dr. Arne Babenhauserheide [2020-11-24 21:51]: >> >> Jean Louis writes: >> >> The start of the local variables list should be no more than 3000 >> >> > characters from the end of the file >> >> >> >> >> >> Given the length of the email, I guess this is why Emacs saw the vari= ables >> >> as being within the correct range. >> > >> > Yes thank you. I was thinking Emacs will do that only in files where >> > it recognizes some comments or no comments and that variables need >> > to be pretty down in the file, on the bottom. Now I learn it is not >> > so. >> > >> > That is security issue. >> >> Why is it a security issue? The variables do need to be close to the end >> =E2=80=94 3000 characters is only about 50 lines. > > Emacs users, Org users on our mailing lists are not so private. Their > names and email addresses are in the public database. Spammer can > construct phishing type of an email, including something like Org news > or something and send such email to users. Among let us say 3000 > people there will be percentage of users that will say Y to invoke the > local variables due to lack of knowing what is it doing to computer. > > After that, anything becomes possible, including intrusion into > computer, capturing all email addresses, passwords, sending spam > emails from computer and so on. this is just baseless fear mongering based on nothing but speculation. Of your suggested 3000 users, only a very small percentage use Emacs as their mail client. Of those, only an even smaller number will have their mail client configured to render messages with a mode that supports local variables and even a smaller number of those would say yes to executing the code. In fact, anyone who has gone to the extent of configuring their Emacs email client to open messages with a mime type of x-org (or even just based on an attachment with *.org in the file name) is more than likely to be sufficiently technically aware not to say yes when asked. Few, if any user, is going to download some random attachment in an email message, open it in emacs and then say yes to a message warning them that doing so might be dangerous. Such ill-informed users have been pretty much weeded out by all the other scam phishing out there by now. To convince them to go through such steps would require some pretty convincing content - a simple org news attachment or similar is unlikely to do it. Even if you do get them to say yes, they are still a long way from being able to compromise the computer Emacs is running on. Gaining some level of access is one thing, actually being able to do something with that access is another. Trying to compromise a computer, which these days typically involves privilege escalation, would be extremely difficult to achieve with elisp. The best you could hope for would be to install a trojan or back door what would allow the attacker to install other tools. Could be possible, but is definitely non-trivial. This ability has been around in Emacs for a very long time - more than 30 years, possibly even longer. There has not been a single recorded incident of large number of users being compromised as a result of this feature. I've not even heard of small numbers being compromised as a result of this feature. I'm sure you will disagree. My suggestion is that if you believe this is a security issue, you put together a proof of concept to demonstrate the vulnerability - this is how such security issues get resolved. Demonstrate how the security issue can be exploited with actual proof of concept code rather than mere speculation and that will provide something concrete which can be dealt with. I suspect you will find it much harder to achieve once you actually try to make it work. -- Tim Cross