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 ms0.migadu.com with LMTPS id QAEgOjZYmmGAegAAgWs5BA (envelope-from ) for ; Sun, 21 Nov 2021 15:31:18 +0100 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 OHnDNTZYmmGOFAAAB5/wlQ (envelope-from ) for ; Sun, 21 Nov 2021 14:31: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 0C8B5297F1 for ; Sun, 21 Nov 2021 15:31:18 +0100 (CET) Received: from localhost ([::1]:39368 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1monsD-0003E5-4C for larch@yhetil.org; Sun, 21 Nov 2021 09:31:17 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47806) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1monrl-0003Bb-4y for emacs-orgmode@gnu.org; Sun, 21 Nov 2021 09:30:49 -0500 Received: from [2607:f8b0:4864:20::62b] (port=46008 helo=mail-pl1-x62b.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1monri-0004fE-Bl for emacs-orgmode@gnu.org; Sun, 21 Nov 2021 09:30:48 -0500 Received: by mail-pl1-x62b.google.com with SMTP id b11so11873723pld.12 for ; Sun, 21 Nov 2021 06:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=references:user-agent:from:to:cc:subject:date:in-reply-to :message-id:mime-version:content-transfer-encoding; bh=AxebRzXIKrdu7Lb5DRVEh0pF8p3RpcqlsP5boXXvsLY=; b=ekEplFGPGwoS9siYB1bif/8m+1OjqnqDHXsguQ4f4YCAvNcUS8VmIC/DqErufCIYpR WGUsWj0Qx5wZzzw+NwurQUjV2viasAmkLjO6Cn35ExznKKvHyqVvlR7pfVnIcLuJf9hG m46IL7FkgdNFhH0CbgZ4Z9ZLMKa30NZY/ZetPTWzZgRuZMAAktVA1jgIxLsr0qy7c8Xh sloi+3qxTQhYayqg3cJQFp5k9FMq9I/d608jKkAvBb4VI1MwLGZ083QuEZIwl7iDpBDQ buk6EP3vJ1+dw44aVl6JPKP2wTGebPRXb5eGf97Cs7wahoKsBAY+oYTTXMZvzKSvSw4p htkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:references:user-agent:from:to:cc:subject:date :in-reply-to:message-id:mime-version:content-transfer-encoding; bh=AxebRzXIKrdu7Lb5DRVEh0pF8p3RpcqlsP5boXXvsLY=; b=yadoVzKNHxZQ8PX84yrV6c7zBhLI1QhpNtf209zJLXfksCH8KujokgAvw3dZPMArBV Hyk7pdgBxt5bGHJdvk+G5G0hycPyJiAJZhBTbW8h32IDofEL4NycaCONJPcHRHgsMDgV xoYND73IxgW3cTzjUCgARKr9iRfj15QNR5cGX5VgePOiGCU5IB7mDSJv3lC9zKJVmrgB GqpLjkC7o1ghae0hJnALEBiHHz7ixbuDpBHlaNAmwgqxTbdoZSVK2rACMUcoqq5edueh BJ5M9nSeUTPj3uC85umiit6Mx+nR4PEjhiI2Pt6vPe0e0+1iNXwJ1ovVWSTdNFntvIKh qVgA== X-Gm-Message-State: AOAM533vR15E1IcyqVvvL/BtRWGdfaScudwctqQRBzv9OI/wRUMrJZfr 4Mf8Gzy+15ddcQD5pztbvsQeyBGhNPI= X-Google-Smtp-Source: ABdhPJwl+8kmmaOo/jbFB5jpInZoAFIjsf3PzEWdXGZfn38I5qhzItWCC6Iibp6SLVyPHe8oI2JoHw== X-Received: by 2002:a17:902:c407:b0:142:28fe:668e with SMTP id k7-20020a170902c40700b0014228fe668emr96571195plk.31.1637505044530; Sun, 21 Nov 2021 06:30:44 -0800 (PST) Received: from dingbat (2001-44b8-31f2-bb00-beb4-1dd8-aeda-43dc.static.ipv6.internode.on.net. [2001:44b8:31f2:bb00:beb4:1dd8:aeda:43dc]) by smtp.gmail.com with ESMTPSA id a19sm3918407pgv.42.2021.11.21.06.30.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Nov 2021 06:30:44 -0800 (PST) References: <875yuh9b3t.fsf@gmail.com> <87czojh6m4.fsf@gmail.com> <8735ntg3ve.fsf@gmail.com> <87mtm1e5lt.fsf@gmail.com> <87pmqwt6zi.fsf@gmail.com> <874k87850s.fsf@gmail.com> <87ee7a5xif.fsf@gmail.com> <87wnl26sxv.fsf@gmail.com> User-agent: mu4e 1.7.5; emacs 28.0.60 From: Tim Cross To: Timothy Subject: Re: [PATCH] Accept more :tangle-mode specification forms Date: Mon, 22 Nov 2021 00:51:19 +1100 In-reply-to: <87wnl26sxv.fsf@gmail.com> Message-ID: <87czmtzilr.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::62b (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::62b; envelope-from=theophilusx@gmail.com; helo=mail-pl1-x62b.google.com X-Spam_score_int: 7 X-Spam_score: 0.7 X-Spam_bar: / X-Spam_report: (0.7 / 5.0 requ) APP_DEVELOPMENT_NORDNS=1.997, 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, PDS_HP_HELO_NORDNS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: emacs-orgmode@gnu.org Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1637505078; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=AxebRzXIKrdu7Lb5DRVEh0pF8p3RpcqlsP5boXXvsLY=; b=MMM+HziUYnNaP+ePd+obD5K1wWVaiBFk0b/qkbY7VGLeZgTU8eu7G1TUxlmtSHSRMdAo+o JuwaGv53r2Rr04Motg3d/59YhZcZOqn78edYEV2lQ802j0weUzHESHT/smm4eNU9iZ99Hh ZfQHyLQcjaP0PQZUH/pfPI2mKl+Igjvyj4CKtQqLNAbUouefIxrDV4VAIjknFzdpSXL72Q m1CX+nu6T3TDO9VJskyV5i1Opvcda2cJtX7+n9W5SXQ2UzXqSn5kKnQsLwbwD0QEzTu1kU OPCktBT0418nGsUfbw7lsDoDy8dDj696NhXUOatTyV6TkA6O/S359A1RQ1F/bA== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637505078; a=rsa-sha256; cv=none; b=QW/E2PpyJwkjgObIBZKPx7zabmsM4sl0YzUn36p1aptW2YoWRUmMGMWqlzdApfKPy10ZJj bsAHIpt46yZIYofuVjatnXVkNuoZzKO9DX+qJYiV+ef8apwhfO1qpRe1mvZqSjkAaGl+xV dL9MK8SPB5cjj09mzOdYnO2YPQAKznrFqy9EDFoqtYpxKm1EXp94Y/Whr6crcJoW1sOkFz wFYCaebcEok1KmPQq8E5B4sFkTSERLcnqyIfSRGBYIyHY8iNYvA05dw4FC1oWahTO9R5tZ 3hQg26WFddViwMn+yQArIZK9xZTnLyqUI+pUwt7BjMX7y50qxkOQqSj3BO9sOQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ekEplFGP; 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-Migadu-Spam-Score: -4.08 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ekEplFGP; 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-Migadu-Queue-Id: 0C8B5297F1 X-Spam-Score: -4.08 X-Migadu-Scanner: scn1.migadu.com X-TUID: +1KZQilQ96m3 Timothy writes: > Hi Tim, > >>> The parsing of =E2=80=9C555=E2=80=9D to the integer 555 is done by >>> org-babel-parse-header-arguments, and so can=E2=80=99t really be change= d. >> >> I don't understand this. Why can't it be changed? > > Well, it can't be changed without changing > org-babel-parse-header-arguments, which is quite a major change and I > suspect may be a breaking change. > > Maybe it's fine? I just don't feel confident about this. > >> When I said disable base 10 values, what I meant was generate an error >> if the value looks like it is base 10 i.e. does not have a leading o or >> #o. This makes it clear it has to be specified as an octal value and >> will alert users to this fact. > > This is all well and good, but the point I'm making is that since due to > the current behaviour of org-babel-parse-header-arguments we can't > distinguish between :tangle-mode (identity #o555) and :tangle-mode 365 > putting this idea /into practice/ doesn't look like it will be easy. > I don't see the complication here. When you call org-babel-parse-header-arguments, it returns an alist of argument name and value. If you had a header like :tangle-mode 555, you get the value (:tangle-mode . 555), if you have :tangle-mode o555, you get (:tangle-mode . "o555"). My suggestion is simply to look at the value and if it is not a string, reject it outright. If it is a string, then match that string to the allowed formats (i.e. an octal value if it starts with "#0o" or "o", a symbolic value if it matches a regexp for symbolic representation and even possiblly your ls -l format if it matches that. This is not a change in org-babel-parse-arguments, but rather a change in how we interpret those arguments.=20 > It's also worth noting that with regard to the recent changes that have > been made, this is not a new issue. Which I don't think is a valid argument for the status quo. Allowing base 10 mode specifications is just a bad idea. The fact it has been permitted in the past is likely just an oversight rather than intentional behaviour. Given the potential security issues involved here, I think we can legitimately obsolete such features (using acceptable change management approaches with suitable notification for users etc). > >>> I think the ls-style is quite valuable for two reasons. It=E2=80=99s >>> well-established thanks to ls, and is particularly good for >>> understanding permissions at a glance. >> >> I would agree it is an established way to display the permissions >> associated with a filesystem object, but disagree it is a well >> established way to set such values - I know of no other tool which uses >> this format. > > The driving motivation here is that while the tools which you mention do > not use this for setting permissions (e.g. chmod), they are only used > for /setting/ permissions. Since Org files aren't write-only, and > occasionally we go back and look at what we've written :P I think > allowing a format that is optimised for ease-of-reading instead of > ease-of-writing makes some sense. It is in this respect that I think > ls -l style is a good idea. > I understand your motivation. I dispute your claim it is an established and common convention.=20 >> It is also not the same as the ls -l display (no object >> type indicator). The ls -l also displays sticky bit, uid and gid. Does >> your format also support setting these values (something which can be >> done with the octal or symbolic formats) i.e. support s, S, t and T for >> the 'executable' bit for user/group? > > Ah, I'm afraid that I'm not that up-together on sticky bits. I suspect > that it's not just the ls -l style that will need tweaking. I'll read up > on this in the next few days and update the ML. > This is very difficult Timothy. I really do appreciate all the work you have done here and your patience, which makes what I'm going to say all the more difficult. My big concern here is that you don't understand this area with sufficient depth of understanding to really appreciate some of the subtleties involved here. This makes me concerned that any implementation of a new way to specify mode settings may have some unexpected side effects or hidden issues which could be exploited in unexpected ways (worse case) or simply have unexpected bugs which result in mode settings which are not what the user intended. As someone who has used Unix since 1980 and Linux since 1995, I've experienced my share of issues relating to file modes and their interaction with different filesystems, NFS, different platforms, character sets, locales etc. Implementing a new approach as you are proposing is something I would be extremely wary about. If you do plan to go forward with this approach, please ensure you are very confident in your understanding of the sticky bit, setuid/setgid and associated interaction with execute etc.=20 I suspect you do have the skills to implement correctly given sufficient time, testing and motivation. However, I am concerned your initial stab at this may be somewhat naive and requires more consideration. My main concern is that once you take all the subtleties into consideration, the complexity of your ls -l approach will exceed its utility and maintainability. I could also be completely wrong.=20=20 >> Personally, I prefer the symbolic form as it is shorter and clear. I >> find the ls -l form too easy to get wrong (especially with getting the >> number of '-' correct). > > Isn't choice a great thing? :D In seriousness, this is exactly why I > think it's worth providing these options. At least thinking back to when > I started using Linux a few years ago I would have said the same thing > about the octal form, and was completely unfamiliar with chmod. I expect > different people to have different preferences with these three options, > but for one of them to be something most people are happy with. > Choice is good. However, as I mentioned ina previous post, the problem with choice is complexity and the biggest source of security problems is complexity. Keep in mind that what you do now is something which will need to be maintained by others in the future. It needs to be clear, concise and as simple as possible (but of course, no simpler!).=20 >>> Tim suggested that invalid forms should cause tangling to fail, but I f= eel this >>> may be a bit much. Personally I=E2=80=99m inclined to either >>> =E2=80=A2 warn, and don=E2=80=99t touch the file permissions (this is w= hat currently occurs) >>> =E2=80=A2 use a very conservative file permission (e.g. rw=E2=80=94=E2= =80=94-). >> >> I'm unsure on this. My concern is people may not notice the warning and >> then be surprised later. Given the potential security issues, a later >> surprise is something to be avoided even if it is inconvenient. With >> respect to the default action to take, I would suggest we also need to >> look at the default umask setting for the user and if that is more >> restrictive, use that rather than some value like rw------- For all we >> know, the user has set a specific umask for a valid reason and will be >> surprised if emacs just ignores that to do what it wants (another >> surprise to be avoided). > >> The user is not required to specify a mode. However, if they do and if >> we cannot interpret what they have specified without ambiguity, we >> should throw an error and cease processing. Making a guess as to what >> they intended in this situation is IMO a big mistake. > > I don't see how using the default permissions is a potential security > risk? Could it surprise the user, yes, but that seems unavoidable when > the user is doing something invalid. Consider this simple scenario. The tangled output is being written to a directory which requires specific permissions for security reasons - perhaps it is some type of ftp server where permissions will determine what can be seen by whom. The data might contain sensitive information. The user specifies what they thing is the correct mode specification, but the7y get it wrong. Org comes along and looks at what they specified and decides it cannot interpret what the user has specified, so applies a default (and potentially completely wrong) mode, exposing sensitive data to others who should not have had access. Use a default if the user does not specify a mode, but if they specify a mode and org cannot interpret what they specified, then do nothing - don't generate the tangled output at all. This is the only safe approach.=20 > >> My only preference for "#o" over just "o" prefix is to clearly signal to >> the user that it is an octal value and avoid the situation where you >> might glance a value and see the leading 'o' as a '0', missing the point >> it is an octal value not a decimal one. However, this seems like a low >> risk, so I'm happy either way. > > Well, I've got "o" for now but that's not set in stone. With a lower > case "o" I feel the risk for confusion with "0" is quite low (besides > which a "0" prefix seems to be the C-style for octal anyway). > I am not overly concerned about this one. I merely mention the use of "#0" as a possible approach and why. If the preference is just to have 'o', that is fine with me. My main point is that when it comes to parsing the value, having "#o" as a prefix for octal values is possibly slightly easier wrt regexp specification than just 'o' as 'o' could also be the first character for a symbolic mode specification as in o+w.