On Mon, Apr 27, 2020 at 10:55 PM Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > 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. > 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@xxxxxxxxx/ > [3] https://lore.kernel.org/git/pull.615.git.1587588665.gitgitgadget@xxxxxxxxx/ > [4] https://lore.kernel.org/git/pull.620.git.1587767749.gitgitgadget@xxxxxxxxx/#t > [5] https://lore.kernel.org/git/20200422155047.GB91734@xxxxxxxxxx/ > [6] https://lore.kernel.org/git/cover.1588031728.git.jonathantanmy@xxxxxxxxxx/ > [7] https://lore.kernel.org/git/20200420224310.9989-1-carenas@xxxxxxxxx/
