Preparing for a Git 2.26.3 release

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/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/