From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id cEmFIC5dmmFJhQAAgWs5BA (envelope-from ) for ; Sun, 21 Nov 2021 15:52:30 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id yEU6HC5dmmECEAAA1q6Kng (envelope-from ) for ; Sun, 21 Nov 2021 14:52:30 +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 0A7358A93 for ; Sun, 21 Nov 2021 15:52:30 +0100 (CET) Received: from localhost ([::1]:51024 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mooCj-00032I-7L for larch@yhetil.org; Sun, 21 Nov 2021 09:52:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:51958) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mooBr-00031v-5k for emacs-orgmode@gnu.org; Sun, 21 Nov 2021 09:51:35 -0500 Received: from [2607:f8b0:4864:20::102a] (port=39650 helo=mail-pj1-x102a.google.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mooBo-0007cj-Na for emacs-orgmode@gnu.org; Sun, 21 Nov 2021 09:51:34 -0500 Received: by mail-pj1-x102a.google.com with SMTP id y14-20020a17090a2b4e00b001a5824f4918so14759937pjc.4 for ; Sun, 21 Nov 2021 06:51:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:references:user-agent:in-reply-to :message-id:mime-version; bh=RFhW9DDSwR2h127b3JRt9Zzrb91R/3sew0WA8DXYkZs=; b=ZLhZmugOmVOGJo0ixXwOW78+wnLTTutG/NGmlgVbj+kppXN9HUy0+xs5SeFa8UgurX idYh7STWqHEiA4EA4f8px0IWgG6nodiZX+Pewo6Mh54Q1/J9Ju+Ps+lRrXm+jQJP7iK9 6qCa+0ipTfXeiupKQYPFEMC6pD66ajct0tQihZx3nPANo2+mVl8msIHenIH7jQ4O+Ei6 bGwWkK5x8MyYFyEfK1ePUc2o5ZbfiwGhTFcQEWyJQDgDAw7yJAjGaKFqXl2GqVNyYr3B i2CEZSF64ZoW4+GG7MSxy8qgVEk+dOKCgRAjuW+hCQmGjlB6JjjlCFNJcTHPV6gJWCMB 6ylA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:references:user-agent :in-reply-to:message-id:mime-version; bh=RFhW9DDSwR2h127b3JRt9Zzrb91R/3sew0WA8DXYkZs=; b=NjxrNHlA2DsV/OWqS+CqxG0Kddhsm3cbdeMCIE+Oq+io27k/vQbnI7xoG+b8xqJH6U THjZpbES+Tp03AHkjJxodlKHEW67a8/+kGSeTCG1uLaulMYudGOdW7cN9WaEyh+ZP2dZ bPdFIhDyvOgp7ioNBmZxKzEZpjjgOaKhlYHSzKRSVOFfSe18pDPgbt8bdUTRDeTi2+2I BI4ytCJYBHx4RKIEZOHVYE3wjvaOMRoSbbcuB+ZWP896f+1NWhVf5IKNCEAkF31Gu99Z uzaoBVPhXQMCnlkRl8wPQuetaFVQ6JaHLGuK0kpBoXwm3339BP1JVWWJtM6HlW6WaZuJ xXQQ== X-Gm-Message-State: AOAM530zA3P529oYq7tUBmpR6q8yC1K40w4j+I0kzwSqfnsuUk8Qreyw iYGhRSCm6ZYhBy4bsurHSdI= X-Google-Smtp-Source: ABdhPJybRtInLR5CK1GVojobEXUbt0eicSlSNF5kS+KRXStsfSc6H5sBHtxBXADaJRU8/2+3BEBuYw== X-Received: by 2002:a17:90b:fd5:: with SMTP id gd21mr22282646pjb.37.1637506291043; Sun, 21 Nov 2021 06:51:31 -0800 (PST) Received: from localhost (61-245-128-160.3df580.per.nbn.aussiebb.net. [61.245.128.160]) by smtp.gmail.com with ESMTPSA id l12sm5904403pfu.100.2021.11.21.06.51.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 21 Nov 2021 06:51:30 -0800 (PST) From: Timothy To: Tim Cross Subject: Re: [PATCH] Accept more :tangle-mode specification forms Date: Sun, 21 Nov 2021 22:33:58 +0800 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> <87czmtzilr.fsf@gmail.com> User-agent: mu4e 1.6.9; emacs 28.0.50 In-reply-to: <87czmtzilr.fsf@gmail.com> Message-ID: <87mtlx7ea9.fsf@gmail.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Host-Lookup-Failed: Reverse DNS lookup failed for 2607:f8b0:4864:20::102a (failed) Received-SPF: pass client-ip=2607:f8b0:4864:20::102a; envelope-from=tecosaur@gmail.com; helo=mail-pj1-x102a.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=1637506350; 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:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=RFhW9DDSwR2h127b3JRt9Zzrb91R/3sew0WA8DXYkZs=; b=YHotboHLMmBmguGf0HV5a0545IQaALIqq+8XLjThddIR57yOA5klTgyvwr26D9NDM6KPsL 7ilfGic3BDI2D56RxviCRP/SG1WIFnGrCI3odCJkP0DGvckoKnkXQ1eA7k7M9CSm6mnH82 iBAJFKeOfCP3EtmK76aWcF+25UwsJFsboh70XL78f4r5tDdOG8JjPssR0dPU/bK1UslYYu UdyGVvg6fCDtazU4vWNzuQ1LwkRsym9MhPOl859Ew8lmodwuFVK7hi3Nh3B+IdfSZWrj+j 0FYAyKTPl0NGDyazQaSzijWTKaESquuCz/gIZZhehitakbo7tE7kAuyZc/1ZdQ== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1637506350; a=rsa-sha256; cv=none; b=ux19LlUqdUjt3mlJuaRkn0YzZAO1HUEoMTfymRqDNkhOve6EigTifwvX6Cxn6o6ATrEaWD dfJOauHkB9R/8DDkrLUMEHc8zoT+BPAGCY/lL98EVxMjsya2Y1pDvZ7M848y3mZ44t491v GNjuZdWPdTjro1vY+AOy6R0GNZSPy8C8HVsnvcib50ff/f/prdLVAMSyUoWogf/EHugP2E lXUqgRxqgGQxKlDGKOdfh0U1ldwV1VLRfY4Hs6gFDBrNEn3hGPMuaWp/m+uJi8e8uRN67q 6BTKkp4C7hC5wNC8eVIVaAJDSlPQhv63zcdOKjDpZOyHFifSWrM1QPDqEkU3XA== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZLhZmugO; 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: -3.08 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=ZLhZmugO; 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: 0A7358A93 X-Spam-Score: -3.08 X-Migadu-Scanner: scn1.migadu.com X-TUID: TWMr2G0ibwF9 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Tim, Thanks for the way in which you=E2=80=99ve responded to my comments. I appr= eciate the effort you=E2=80=99ve gone to to explain your views as opposed to simply sa= ying you disagree with some of my current thoughts :) Tim Cross writes: > My suggestion is simply to look at the value and if it is not a string, r= eject > it outright. [=E2=80=A6] This is not a change in org-babel-parse-argument= s, > but rather a change in how we interpret those arguments. Ah I see, I did not think you were suggesting this. I=E2=80=99m quite wary = of this as it would break all current `:tangle-mode (identity #oXYZ)' headers, which as I understand it are /the/ way tangle-mode has been previously set. Perhaps this is a good argument for deprecation? I think we=E2=80=99d need = to give a decently long transition period though (a few years). > 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. I think we are of the same mind regarding base10 permissions specifications being bad, but are niggling over what to do about this. > 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=E2=80=99m certainly open to deprecation, though I=E2=80=99d like to hear = from some of the other =E2=80=9Cmain Org people=E2=80=9D (e.g. Bastien, Nicolas) before doin= g anything along these lines. Perhaps this would be worth making a second thread for? > I understand your motivation. I dispute your claim it is an established > and common convention. Ok, cool. Since we should have a while till the next Org release, nothing i= s set in stone yet and hopefully this will give us time to see if the ls -l forma= t is fit for purpose or not. I think it will be, but correctness is of course mo= re important than niceness. >> [sticky bits and the ls -l format] > > This is very difficult Timothy. I really do appreciate all the work you > have done here and your patience, which makes what I=E2=80=99m going to s= ay all > the more difficult. My big concern here is that you don=E2=80=99t underst= and > 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=E2=80=99ve experienced m= y 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. Thanks for explaining your position thoroughly here. I don=E2=80=99t need a= ny convincing that a solid understanding is necessary for a good implementation. I had a = quick peek and estimated the time I=E2=80=99d need to properly come to terms with= sticky bits =E2=80=94 hence my estimate of a few days before I look at implementing this. > 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. I=E2=80=99ll let you (/the ML) know when I=E2=80=99ve taken a look at stiky= bits, and whether I think I=E2=80=99m able to create something that works. My intuition is that= if ls -l can properly represent sticky bits (and my rudimentary understanding is that it= can) it should be fine for specifying them too. We=E2=80=99ll see. > Choice is good. However, as I mentioned in a 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!). I like to think that the current implementation is fairly short and clean. = If I can=E2=80=99t add sticky bits =E2=80=9Cnicely=E2=80=9D, I=E2=80=99ll recons= ider things. > 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=E2=80=99t generate the tangled output at all. This is the only safe > approach. Thanks for the example. This sounds reasonable to me, and has prompted me to test what=E2=80=99s actually happening at the moment. Seems like the user-error I raise actually causes the tangling for that file /and all subsequent files/ to fail, i.e. no content is written. It looks li= ke we actually want to loosen the current behaviour :P Alright, that=E2=80=99s it for now. You can expect an update in a few days = on sticky bits. All the best, Timothy --=-=-=--