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 9afad1cd for ; Sat, 20 Apr 2019 10:28:33 +0000 (UTC) Received: (qmail 25934 invoked by alias); 20 Apr 2019 10:28:18 -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: 44237 Received: (qmail 11820 invoked by uid 1010); 20 Apr 2019 10:28:18 -0000 X-Qmail-Scanner-Diagnostics: from mail-it1-f193.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.166.193):SA:0(-2.0/5.0):. Processed in 1.103237 secs); 20 Apr 2019 10:28:18 -0000 X-Envelope-From: mikachu@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.166.193 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=F/a+0LE7KhaBWlhH5Y90vcB0TR5x849+8wQd+6nf928=; b=TWyfIDeIIEd1VVFvAe+mzVrr0bHXdKRRp6VJl1rSUkzn5CYrvPzvQPyBe+PmYPHysW z08nzJgW+LanbjumIQ+Ub4coKmvVg7+1wKqZqthPFTjKJuLDu/Z2UUj9uzUV76vyfZU4 AtSGffr0AKKU+ynY5QYiRnh8/H1GHG1rwUJ4TE5MUmlEUbnVPLqdmLY68bHoh6E88GKW J6BguW6IwGpd+n2CKWdRs6V/YkUNRmWSHZsptUJU80/jorqWERjuaPuVhx7CgwI4lzlN Yv4gJf7OcFK7hPTrg0P8U92QOahk3OdFs2f2uETCWBOheJVcxL8y0pFoyx8EjgWAPAES LX7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=F/a+0LE7KhaBWlhH5Y90vcB0TR5x849+8wQd+6nf928=; b=ui6i0NkEOg04ogpMNgtpfpZEyTP6g5mScwHLq6FoUn1HpZ+c4zS8nh7NGeiuxNl2CF f+7aGP35i13VGXKycaquf2pha+scUlTFTCEmYEFwj44vEpuNOJbTIInJIl4TqcsV+TVr kTxqj8OJL/8pC765EnWiE71TET67oVKCOa3TJYgUWmzTYNpmgnOUBQ0hYpfF8441TlYB X+/KUGJH9TxhR/Xf4xJjhEojcigSiD+lzjCk5u7sB/yWqiirvR7qzp4PoYEyRqXob7+D rq/v6km91QnU+xQFhrdPjuxg4qhkXscXCUbi7unrGS6TAQHYyUGVLF+3bsw506BqNBTI Fw8w== X-Gm-Message-State: APjAAAVAxszVKj1HYBRW3ZUrBmq+4UxmLu2pJXas37iX7kYzuSVQrV6h 6QAZBNN3UHIy1YlMzMG6Sz/yPpywK+ZkKt8DpuxCVg== X-Google-Smtp-Source: APXvYqwdDSB8wKY5T9vfbomTLjmmzyFa2U9fvES0gZSxxe8bA+FumI4mQJPWboaVxFzRKrnuhezwjIsKtbIr1kVJvNU= X-Received: by 2002:a02:6c83:: with SMTP id w125mr6216453jab.20.1555756063187; Sat, 20 Apr 2019 03:27:43 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20190420043349.GA52075@CptOrmolo.darkstar> References: <20190420043349.GA52075@CptOrmolo.darkstar> From: Mikael Magnusson Date: Sat, 20 Apr 2019 12:27:42 +0200 Message-ID: Subject: Re: [PATCH] replacement for mktemp and mkstemp code in Src/utils.c To: Clinton Bunch , zsh-workers@zsh.org Content-Type: text/plain; charset="UTF-8" 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. 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). -- Mikael Magnusson