From: Matthew Martin <phy1729@gmail.com>
To: Clinton Bunch <cdb_zshl@zentaur.org>
Cc: Mikael Magnusson <mikachu@gmail.com>, zsh-workers@zsh.org
Subject: Re: [PATCH] replacement for mktemp and mkstemp code in Src/utils.c
Date: Sat, 20 Apr 2019 23:57:28 -0500 [thread overview]
Message-ID: <20190421045727.GA18772@CptOrmolo.darkstar> (raw)
In-Reply-To: <5315c85d-abda-fdb5-271f-22a7805eea27@zentaur.org>
On Sat, Apr 20, 2019 at 01:52:24PM -0500, Clinton Bunch wrote:
> Mikael Magnusson wrote:
> > On 4/20/19, Matthew Martin <phy1729@gmail.com> 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.
next prev parent reply other threads:[~2019-04-21 4:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-19 19:54 Clinton Bunch
2019-04-20 4:33 ` Matthew Martin
2019-04-20 10:27 ` Mikael Magnusson
2019-04-20 18:52 ` Clinton Bunch
2019-04-21 4:57 ` Matthew Martin [this message]
2019-04-21 20:08 ` Mikael Magnusson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190421045727.GA18772@CptOrmolo.darkstar \
--to=phy1729@gmail.com \
--cc=cdb_zshl@zentaur.org \
--cc=mikachu@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).