From: Jeff King <peff@peff.net>
Date: Thu, 21 Feb 2019 13:52:07 GMT
Subject: Re: [PATCH 1/1] mingw: safe-guard a bit more against getenv() problems
Message-ID: <20190221135207.GA20899@sigill.intra.peff.net>
In-Reply-To: <53e3d159c8c80924188f57c44efd2170612f2ee5.1550243863.git.gitgitgadget@gmail.com>

On Fri, Feb 15, 2019 at 07:17:45AM -0800, Johannes Schindelin via GitGitGadget wrote:

> From: Johannes Schindelin <johannes.schindelin@gmx.de>
> 
> Running up to v2.21.0, we fixed two bugs that were made prominent by the
> Windows-specific change to retain copies of only the 30 latest getenv()
> calls' returned strings, invalidating any copies of previous getenv()
> calls' return values.
> 
> While this really shines a light onto bugs of the form where we hold
> onto getenv()'s return values without copying them, it is also a real
> problem for users.
> 
> And even if Jeff King's patches merged via 773e408881 (Merge branch
> 'jk/save-getenv-result', 2019-01-29) provide further work on that front,
> we are far from done. Just one example: on Windows, we unset environment
> variables when spawning new processes, which potentially invalidates
> strings that were previously obtained via getenv(), and therefore we
> have to duplicate environment values that are somehow involved in
> spawning new processes (e.g. GIT_MAN_VIEWER in show_man_page()).

Belated review, as this is already in master, but: yes, I absolutely
support this patch, even on top of my patches. Those were just the cases
I found by poking around for a few minutes, and I'm sure there are many
more.

-Peff