From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from primenet.com.au (ns1.primenet.com.au [203.24.36.2]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 4ae7be1f for ; Sun, 21 Apr 2019 04:58:25 +0000 (UTC) Received: (qmail 16618 invoked by alias); 21 Apr 2019 04:58:06 -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: List-Unsubscribe: X-Seq: 44240 Received: (qmail 5566 invoked by uid 1010); 21 Apr 2019 04:58:06 -0000 X-Qmail-Scanner-Diagnostics: from mail-oi1-f195.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.101.1/25419. spamassassin: 3.4.2. Clear:RC:0(209.85.167.195):SA:0(-1.8/5.0):. Processed in 1.457553 secs); 21 Apr 2019 04:58:06 -0000 X-Envelope-From: phy1729@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.167.195 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=iEeCkm/ndeUsAmcpoEn710HFc5dNmWqag2VCE5Y8dVg=; b=nu6Z0Mx7xiVybpEWwS7oPNb/qYb/voIDeisVLNpeV6IFlmVhMBQ4S90N6xM0ogrY8I K/Qk1ghPzEAbdu7hWv5eNS946s1ZUrMqxRuryjlvUH6Xx84lv9o9QFf1ThMbjK8wcWL0 CnmcP19OBqscGeTZS8S4iMAiw2wlkuNm4ULWsH9TzgHDZBuYB1UiBCRI9Sis8Xn+VfEM gEKCfRXpWunpvzLTh2/Ee4c8yKJ4nRngST74XRY+EKvYhrbeOGWWSizODounE+41xgEp ytfH99b+8Z0QAAfQen4eotBv79eyzBNB4r+tmufh4OcOGEPEjmSy3aCgTbPauZsiRgNO OMzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=iEeCkm/ndeUsAmcpoEn710HFc5dNmWqag2VCE5Y8dVg=; b=QMEx4DX16ioUnxngQKqRwqwgJsoyzqQJwmhlGPR+7oD3vH63fN96ik86dI2BTa3oxX iYzppzjR6fifpxBkEds4c/woLc2RAxCRwB24xdOJI++nFLFXLBH6lIsyqIH8voi3nfZT FB7jZ7tQPzY+mHHO8Fn0dV1wAhduGQFS8RUU2KLwSG6AwrubX7AjCjFa78CMtEnWUW7j l98IOZIM9UAnNIsGVOTy/3OhVhJZWpRz+liaNT8u/3x86RTgTkirYSTkIQCdfNGdW5jv aBSCmK2zcD/OtQqxedpt2slKMYH+L0EWMvC/dL/xk8/uwWb1NsA3YwrdDinM77RjScV0 OKiQ== X-Gm-Message-State: APjAAAVzBot/yCECG+ZKWdWg5yPVbsYZamD3tfF5VO3e/CNlSKyaGOQN biTdfYM/bdG6BNcfPSoNtQQ= X-Google-Smtp-Source: APXvYqxNAa3CdHp7qEqhe+lRsk5ZSb1OelF61+Jn2fUQicCjZtjEs08r+FNH2G4geKRMefNF17Eiqg== X-Received: by 2002:aca:62c5:: with SMTP id w188mr6738978oib.12.1555822651304; Sat, 20 Apr 2019 21:57:31 -0700 (PDT) Date: Sat, 20 Apr 2019 23:57:28 -0500 From: Matthew Martin To: Clinton Bunch Cc: Mikael Magnusson , zsh-workers@zsh.org Subject: Re: [PATCH] replacement for mktemp and mkstemp code in Src/utils.c Message-ID: <20190421045727.GA18772@CptOrmolo.darkstar> Mail-Followup-To: Clinton Bunch , Mikael Magnusson , zsh-workers@zsh.org References: <20190420043349.GA52075@CptOrmolo.darkstar> <5315c85d-abda-fdb5-271f-22a7805eea27@zentaur.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5315c85d-abda-fdb5-271f-22a7805eea27@zentaur.org> User-Agent: Mutt/1.11.4 (2019-03-13) On Sat, Apr 20, 2019 at 01:52:24PM -0500, Clinton Bunch wrote: > Mikael Magnusson wrote: > > On 4/20/19, Matthew Martin wrote: > > > On Fri, Apr 19, 2019 at 02:54:47PM -0500, Clinton Bunch wrote: > > > > This provides an alternate implementation for generating and opening temp > > > > file names. I considered only using this implementation on known bad > > > > systems, but I have no way of knowing all of them (or testing for them in > > > > configure). I see no reason to expect system implementations of mktemp > > > > or > > > > mkstemp to be significantly faster than mine unless written in assembly > > > > (which seems unlikely). > > > I would strongly prefer using the implementation only on known bad > > > systems (or prodding the relevant vendors to fix their system). I don't > > > think speed should be the main consideration here; rather the primary > > > concern should be security. While your patch is certainly better than > > > using the native mktemp on at least one system, it would be worse than > > > the native mktemp on say FreeBSD which uses arc4random_uniform which > > > does not require a user provided seed nor does it have modulo bias. > We still face the problem of determining which systems have broken > implementations. I know of one, that doesn't mean there aren't others. > My implementation could easily be modified to use arc4random_uniform on > those system on which it is available if that's the primary objection. I'd > have used /dev/urandom (at least as a seed) if it were available everywhere. Whichever system has the predictable temp file names, it is a bug in that system not zsh. While zsh can paper over the bug, it would be preferable to fix the broken implementation in that system's libc so that all mk(s)temp calls are fixed not just the ones zsh would make. Including a better alternative for that system is an okay interim solution, but the ultimate goal should be to delete that code when the system's implementation is fixed. A bug in one system is not a reason to change behavior in a separate system. Having all systems use the alternate code results in zsh missing out on any bug fixes or later enhancements in those systems.