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,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 865eb6c4 for ; Sat, 20 Apr 2019 18:54:22 +0000 (UTC) Received: (qmail 12442 invoked by alias); 20 Apr 2019 18:54:09 -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: 44239 Received: (qmail 12968 invoked by uid 1010); 20 Apr 2019 18:54:09 -0000 X-Qmail-Scanner-Diagnostics: from heimdall.zentaur.org 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(45.56.127.49):SA:0(-2.0/5.0):. Processed in 2.45064 secs); 20 Apr 2019 18:54:09 -0000 X-Envelope-From: cdbunch_ml@zentaur.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at zentaur.org designates 45.56.127.49 as permitted sender) DKIM-Filter: OpenDKIM Filter v2.11.0 heimdall.zentaur.org x3KIqMHx006765 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=zentaur.org; s=default; t=1555786352; bh=PiLMljeZJkAHod82XLddxoLIZZNhZUpkskMAqwfmy0g=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gAPONcWe+xmh2pGmVBEJJEfmk3DV5OFah8NTdYgaodmWchyFSZG2oURWLuq9/cRbY feZlrB27RlIHx7E5pCmvwpIrFVjPqVEO4vPvh0oWd3blBoStgce1sRjGWnPj+Wl3/u tli9nGtZP0iPGlPqYnISSseWphGrm1WgCZ2dR52I= Subject: Re: [PATCH] replacement for mktemp and mkstemp code in Src/utils.c To: Mikael Magnusson , zsh-workers@zsh.org References: <20190420043349.GA52075@CptOrmolo.darkstar> From: Clinton Bunch Message-ID: <5315c85d-abda-fdb5-271f-22a7805eea27@zentaur.org> Date: Sat, 20 Apr 2019 13:52:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mikael Magnusson wrote: > On 4/20/19, Matthew Martin wrote: >> 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. 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. > The commit message is incomplete, it claims that mktemp is insecure on > one system, therefore it replaces mkstemp, which makes no sense. Is > mkstemp also insecure on that system, is it not available at all? Do > we not even attempt to use mkstemp? > > Also, please make at least some attempt to use the same coding style > as the rest of the code base, ie try to use the space bar sometimes. > (You're not even consistent with yourself in some places). > mkstemp uses the same insecure naming structure. That is the normal case so it seemed redundant to mention it. Are the code style settings codified anywhere? The tabs were added by Vim's autoident. A set of options for indent or astyle would make it easier for anyone to meet the coding style.