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 8f7a7d12 for ; Sat, 20 Apr 2019 04:34:45 +0000 (UTC) Received: (qmail 22888 invoked by alias); 20 Apr 2019 04:34:29 -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: 44236 Received: (qmail 1075 invoked by uid 1010); 20 Apr 2019 04:34:29 -0000 X-Qmail-Scanner-Diagnostics: from mail-ot1-f68.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.210.68):SA:0(-1.7/5.0):. Processed in 2.798046 secs); 20 Apr 2019 04:34:29 -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.210.68 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:content-transfer-encoding :in-reply-to:user-agent; bh=ZIeBwqv7bOQYRWvI8AIz/loz7ykeaaCcWcu9a33plUM=; b=cFDSNVeHR8WXFPZ93dhoq48SfpUU83jLSPR7VmAsGq0P/W3nw9Lug36cFd2t98Ol5w Gnpy6jbocvCyHoBDs7mYOG/fiRzb81J2q7I7iwDP+OfT9a05uQWzcN1C+Uo2MQvBkYZX IIlSVn1f+/R2NvuE6xb0y0lNRUb3Swc3BHpp9kKEFRVFWtHWp3yWnOJ92/Id4HLBd2wi pWd8fvRKQmHEi6S0gMw/8ZpovLw6fmmdqSDrudrS3RYNMxZWoULHm0nDmp6dgzpuXnnB rDORqIQwK5O4dT2/viCSxy1NWiRYZefjbpXUwGeH2pMim9HKY2TLy6I2YZTrauXNwTJd J1GQ== 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 :content-transfer-encoding:in-reply-to:user-agent; bh=ZIeBwqv7bOQYRWvI8AIz/loz7ykeaaCcWcu9a33plUM=; b=FY09FnriQpf46A8HGKLzbbnrGSGLYa/ZYKNMwSA7S2kDaSsi7bc0xZfIdjGVoAZzYb sw9rVviAQIoMmDH/h49VWCYqdPCFr6zGzQkEWWCqa33IoanuwRe+GKHs/BQJqZ8rCJs6 +j0ca9/3NdwxAR3WC9LclsVvK9p0yJNcroyruSv//o6Ls3sq1snk2eWjOb/P03/NJR9U M0k8zq8Nk1PzyQYIKHuzeGXvjvzhIdxXVJTqA8fREpcIOrDbuCU39BMnPR4+1P4v82+C BxcV6NArems9RMi3gjon3MpoDiDPZV2vQAEkLtehafaH/QqKGGT3uPrCntXAibbJLmdb 7ePQ== X-Gm-Message-State: APjAAAX3cuE4QdrcKgdo5IUgPys40tUj/BT5g127PeHNQ3sx2d1ZRtyj jCiSS0/nrvJ57yafqoG7rbCAxOcSwB0= X-Google-Smtp-Source: APXvYqy1+MssxqIIR2vGPgCMlpIW5pbLynXoRRh+BAm+yYVPEQ7kGjB0B6JC1mky/2utOX75OpUNsw== X-Received: by 2002:a9d:738c:: with SMTP id j12mr4176779otk.119.1555734832868; Fri, 19 Apr 2019 21:33:52 -0700 (PDT) Date: Fri, 19 Apr 2019 23:33:50 -0500 From: Matthew Martin To: Clinton Bunch Cc: zsh-workers@zsh.org Subject: Re: [PATCH] replacement for mktemp and mkstemp code in Src/utils.c Message-ID: <20190420043349.GA52075@CptOrmolo.darkstar> Mail-Followup-To: Clinton Bunch , zsh-workers@zsh.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) On Fri, Apr 19, 2019 at 02:54:47PM -0500, Clinton Bunch wrote: > On at least one system mktemp produces very predictable names: > > % () { print File: $1; cat $1 } =(print "Hello World") > File: /tmp/zsh010785 > Hello World > % () { print File: $1; cat $1 } =(print "Hello World") > File: /tmp/zsh010785 > Hello World > % () { print File: $1; cat $1 } =(print "Hello World") > File: /tmp/zsh010785 > Hello World > % echo $$ > 10785 > > 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.