Re: Preparing for a Git 2.26.3 release

From: Elijah Newren <newren@gmail.com>
Date: Apr 28, 2020, 06:22 UTC
Message-ID: <CABPp-BE+mFCWVkuhs_80qtQwWTtMKo6OfdmG3cmJ98FS7Csxww@mail.gmail.com>
In-Reply-To: <20200428055514.GB201501@google.com>

On Mon, Apr 27, 2020 at 10:55 PM Jonathan Nieder <jrnieder@gmail.com> wrote:

Show 31 quoted lines

>
> Hi,
>
> Last week and the week before Git released 2.26.1 and 2.26.2 in quick
> succession, to address some security issues (CVE-2020-5260 and
> CVE-2020-11008).
>
> Since then we've heard about a few related (non-security) regressions.
> I'd like to avoid giving people an excuse not to upgrade, so this
> morning[1] I promised a discussion of what I'd like to see in a 2.26.3
> release to help with that.
>
> credential_from_url fallout
> ---------------------------
> The credential_from_url hardening affected http.c in the way we'd
> like, but it also affected credential-store[2].  We may want to relax
> that.
>
> (only affects 2.25.y and earlier) The credential_from_url hardening
> also affected credential.<urlpattern>.* parsing[3].  Depending on what
> semantics we decide on for those earlier releases, we are likely to
> want 2.26.y to behave the same way[4].
>
> 2.25.y -> 2.26.0 regressions?
> -----------------------------
> The main major changes from 2.25.y to 2.26.y were the change of
> default rebase backend and protocol.version defaulting to 2.
>
> I don't believe there are any major outstanding issues with the
> change in rebase backend, but I'm cc-ing Elijah Newren to get a chance
> to be corrected :).

I'm not aware of any outstanding (by which I think you mean "unsolved") issues, but there are four short topics fixing regressions in master since v2.26.x (namely: ag/rebase-merge-allow-ff-under-abbrev-command, en/pull-do-not-rebase-after-fast-forwarding, en/sequencer-reflog-action, and en/rebase-no-keep-empty). Some or all of those topics might make sense to include in a stable release if you're considering fixes other than security updates.

Show 39 quoted lines

> The protocol version change was painful for users that fetch in the
> same repo from linux-next and other linux remotes[5].  The problem has
> been isolated and fixed, so we could either apply the revert or apply
> the fixes[6].
>
> credential helper hardening
> ---------------------------
> Lastly, after seeing a v2.26.1 security release and v2.26.2 security
> release in quick succession, I'm looking at what it would take to make
> Git more robust so we don't end up need .3, .4, .5 security releases
> soon after.  Perhaps we can make the credential system a bit more
> robust to prevent future similar accidents.  For example:
>
> - teach in-tree credential helpers to reject repeated fields in their
>   input (Just In Case some variant of newline injection that uses \r
>   or something pops up)
>
> - teach in-tree credential helpers to require the host and protocol
>   fields to be set (e.g., [7])
>
> - update git-credential(1) to document the newly tightened protocol
>
> That might go against the goal of getting rid of excuses not to
> upgrade, though.  Where we see regression potential, we can be patient
> and wait for 2.27, but if we have some examples with particularly low
> regression potential then they might be okay 2.26.3 fodder as well.
>
> Thoughts?
>
> Thanks,
> Jonathan
>
> [1] https://colabti.org/irclogger/irclogger_log/git-devel?date=2020-04-27#l65
> [2] https://lore.kernel.org/git/20200426234750.40418-1-carenas@gmail.com/
> [3] https://lore.kernel.org/git/pull.615.git.1587588665.gitgitgadget@gmail.com/
> [4] https://lore.kernel.org/git/pull.620.git.1587767749.gitgitgadget@gmail.com/#t
> [5] https://lore.kernel.org/git/20200422155047.GB91734@google.com/
> [6] https://lore.kernel.org/git/cover.1588031728.git.jonathantanmy@google.com/
> [7] https://lore.kernel.org/git/20200420224310.9989-1-carenas@gmail.com/