From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17356 invoked by alias); 27 Sep 2016 19:20:44 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 39466 Received: (qmail 11458 invoked from network); 27 Sep 2016 19:20:44 -0000 X-Qmail-Scanner-Diagnostics: from mail-pa0-f51.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.220.51):SA:0(0.0/5.0):. Processed in 0.767075 secs); 27 Sep 2016 19:20:44 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=s1aYmITw4pdsfY+yj5e+z6esKhEbMOISRI58By44zxM=; b=JQqGfmDPCIH523jWYbElhECj+HxGRE1U7H0Dc05Yjl5TDenJ2ENqziPoftVYObeCRw hBcWX40rJx92FQ8//CX+ULOklymG0R3N32l1oAexmEC789A2zm2ajohS0PbfvCXC4tsu tqZBnKERR06x8Y3a7T6vCb8105RX324YaiLg8F6GHpLgWcSIdv+Ht5GbmhTEBLQIJzwM lP3hZ2ziZIONN/0LMpPSqt1OHBN5p2pBnCZ/vdPKgzK81XWO0csTJZDFT97LbwsblEyj wxqqgdFcqVtn7zEt7NSKEmbcAveJEzHqhneYkmMee3LDjffYuUOw1zCy9Fe6uarV+0Yp MCZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version; bh=s1aYmITw4pdsfY+yj5e+z6esKhEbMOISRI58By44zxM=; b=cpQsJZuKITZElVkNLYsX7L5LrQdHSQVNs5k4UtlOYhvR1LqjEdksnMOXYF1FvegXw8 IOjt4er+7VUqutRSXBxMUJ4wsaro+RyHR0Ohhk+Ekf9DXpVu7rEmX+EpAARlFtijfDjs oxrVkd/i3MeODMVvTql9EzXIeaYq2XcPVGVyTque2IXIr88qJCRsxwJNM5GXgZ+CJBcy Zse/pRhnbTIGqbUFVuCetsJMdQj6FPQ2odWQSxw2yUMY9B/z+8ZjL4Dby0IA2mbMwmag 8spQbf1j62K/orqoZLM4I/y1LXG34PzQZ3dz+sf4yENDELLitVFJr63ONawMMluRs5aY 0pNA== X-Gm-Message-State: AE9vXwPwbQ/2cFthhOPoQ8fuz4JNaQP/yYrCUAsgZKVtG4rnS7eDZNG+hDOO9AxWhmRQUg== X-Received: by 10.66.217.170 with SMTP id oz10mr50943700pac.61.1475004037052; Tue, 27 Sep 2016 12:20:37 -0700 (PDT) From: Bart Schaefer Message-Id: <160927122050.ZM13394@torch.brasslantern.com> Date: Tue, 27 Sep 2016 12:20:50 -0700 In-Reply-To: <20160927070039.GA20798@fujitsu.shahaf.local2> Comments: In reply to Daniel Shahaf "Re: PATCH: [for consideration] TMPSUFFIX" (Sep 27, 7:00am) References: <160925155112.ZM23899@torch.brasslantern.com> <20160926072546.GA28316@fujitsu.shahaf.local2> <160926091922.ZM26758@torch.brasslantern.com> <20160927070039.GA20798@fujitsu.shahaf.local2> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: PATCH: [for consideration] TMPSUFFIX MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Sep 27, 7:00am, Daniel Shahaf wrote: } } > won't assert the attack is 100% impossible, but there's nothing more } > we can do about that than we already have. } } Yes, there is: we should stop calling addfilelist(nam) if open(nam) } returns negative. That's not the "that" I was talking about. } (Sidebar: that mktemp() call is the only warning in my build; it'd be } nice to get rid of it while we're here.) zsh-workers had this conversation years ago and landed where we are now (except I don't think this bit about =() returning the name even if it wasn't opened was noticed/considered). } > It'd have to be an error on the same order as "bad substitution" so the } > whole command context fails. Hence bringing it up for discussion. } } I don't know what's best here. } } Using ERRFLAG_ERROR risks aborting too much code (39154 being a recent } example). I'm not sure that's really a valid example for this case -- the trouble there was not that too much code was aborted, rather that because of a surrounding use of "eval" not *enough* code was aborted; a scripting error. } A middle way would be to force the simple command that =(:) was part to } return 127. If we were to parallel other redirection errors, the command should just return 1. Otherwise I'd say we should report the actual error number instead of always 127. However, I don't see any obvious way to do either of those things from inside stringsubst(). The code in stringsubst() expects getoutputfile() to return NULL and then substitutes nothing as the replacement, which could change the number of arguments in the command -- so that isn't ideal either. We could just call zwarn() [instead of zerr()] and return "/dev/null" to supply an empty file as if the command inside the =() had failed, but I'm more inclined to just call zerr() and allow things to abort. This obviously isn't a very common occurrence or we'd have seen it come up before; this is hardly an obscure or little-used feature.