Subject: Preparing for a Git 2.26.3 release

From: Jonathan Nieder <[email-masked]>
Date: Mon, 27 Apr 2020 22:55:14 -0700

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 :).

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/[email-masked]/
[3] https://lore.kernel.org/git/[email-masked]/
[4] https://lore.kernel.org/git/[email-masked]/#t
[5] https://lore.kernel.org/git/[email-masked]/
[6] https://lore.kernel.org/git/[email-masked]/
[7] https://lore.kernel.org/git/[email-masked]/