{"thread":{"id":"53337","subject":"Preparing for a Git 2.26.3 release","startedAt":"2020-04-28T05:55:20Z","lastAt":"2020-05-09T17:12:04Z","messageCount":9,"participants":["Jonathan Nieder","Elijah Newren","Junio C Hamano","Michal Suchánek","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"396437","messageId":"20200428055514.GB201501@google.com","threadId":"53337","inReplyTo":null,"subject":"Preparing for a Git 2.26.3 release","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2020-04-28T05:55:14Z","receivedAt":"2020-04-28T05:55:20Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nLast week and the week before Git released 2.26.1 and 2.26.2 in quick\nsuccession, to address some security issues (CVE-2020-5260 and\nCVE-2020-11008).\n\nSince then we've heard about a few related (non-security) regressions.\nI'd like to avoid giving people an excuse not to upgrade, so this\nmorning[1] I promised a discussion of what I'd like to see in a 2.26.3\nrelease to help with that.\n\ncredential_from_url fallout\n---------------------------\nThe credential_from_url hardening affected http.c in the way we'd\nlike, but it also affected credential-store[2]. We may want to relax\nthat.\n\n(only affects 2.25.y and earlier) The credential_from_url hardening\nalso affected credential..* parsing[3]. Depending on what\nsemantics we decide on for those earlier releases, we are likely to\nwant 2.26.y to behave the same way[4].\n\n2.25.y -> 2.26.0 regressions?\n-----------------------------\nThe main major changes from 2.25.y to 2.26.y were the change of\ndefault rebase backend and protocol.version defaulting to 2.\n\nI don't believe there are any major outstanding issues with the\nchange in rebase backend, but I'm cc-ing Elijah Newren to get a chance\nto be corrected :).\n\nThe protocol version change was painful for users that fetch in the\nsame repo from linux-next and other linux remotes[5]. The problem has\nbeen isolated and fixed, so we could either apply the revert or apply\nthe fixes[6].\n\ncredential helper hardening\n---------------------------\nLastly, after seeing a v2.26.1 security release and v2.26.2 security\nrelease in quick succession, I'm looking at what it would take to make\nGit more robust so we don't end up need .3, .4, .5 security releases\nsoon after. Perhaps we can make the credential system a bit more\nrobust to prevent future similar accidents. For example:\n\n- teach in-tree credential helpers to reject repeated fields in their\n input (Just In Case some variant of newline injection that uses \\r\n or something pops up)\n\n- teach in-tree credential helpers to require the host and protocol\n fields to be set (e.g., [7])\n\n- update git-credential(1) to document the newly tightened protocol\n\nThat might go against the goal of getting rid of excuses not to\nupgrade, though. Where we see regression potential, we can be patient\nand wait for 2.27, but if we have some examples with particularly low\nregression potential then they might be okay 2.26.3 fodder as well.\n\nThoughts?\n\nThanks,\nJonathan\n\n[1] https://colabti.org/irclogger/irclogger_log/git-devel?date=2020-04-27#l65\n[2] https://lore.kernel.org/git/20200426234750.40418-1-carenas@gmail.com/\n[3] https://lore.kernel.org/git/pull.615.git.1587588665.gitgitgadget@gmail.com/\n[4] https://lore.kernel.org/git/pull.620.git.1587767749.gitgitgadget@gmail.com/#t\n[5] https://lore.kernel.org/git/20200422155047.GB91734@google.com/\n[6] https://lore.kernel.org/git/cover.1588031728.git.jonathantanmy@google.com/\n[7] https://lore.kernel.org/git/20200420224310.9989-1-carenas@gmail.com/\n"},{"id":"396438","messageId":"CABPp-BE+mFCWVkuhs_80qtQwWTtMKo6OfdmG3cmJ98FS7Csxww@mail.gmail.com","threadId":"53337","inReplyTo":"20200428055514.GB201501@google.com","subject":"Re: Preparing for a Git 2.26.3 release","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2020-04-28T06:22:24Z","receivedAt":"2020-04-28T06:22:39Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Apr 27, 2020 at 10:55 PM Jonathan Nieder wrote:\n>\n> Hi,\n>\n> Last week and the week before Git released 2.26.1 and 2.26.2 in quick\n> succession, to address some security issues (CVE-2020-5260 and\n> CVE-2020-11008).\n>\n> Since then we've heard about a few related (non-security) regressions.\n> I'd like to avoid giving people an excuse not to upgrade, so this\n> morning[1] I promised a discussion of what I'd like to see in a 2.26.3\n> release to help with that.\n>\n> credential_from_url fallout\n> ---------------------------\n> The credential_from_url hardening affected http.c in the way we'd\n> like, but it also affected credential-store[2]. We may want to relax\n> that.\n>\n> (only affects 2.25.y and earlier) The credential_from_url hardening\n> also affected credential..* parsing[3]. Depending on what\n> semantics we decide on for those earlier releases, we are likely to\n> want 2.26.y to behave the same way[4].\n>\n> 2.25.y -> 2.26.0 regressions?\n> -----------------------------\n> The main major changes from 2.25.y to 2.26.y were the change of\n> default rebase backend and protocol.version defaulting to 2.\n>\n> I don't believe there are any major outstanding issues with the\n> change in rebase backend, but I'm cc-ing Elijah Newren to get a chance\n> to be corrected :).\n\nI'm not aware of any outstanding (by which I think you mean\n\"unsolved\") issues, but there are four short topics fixing regressions\nin master since v2.26.x (namely:\nag/rebase-merge-allow-ff-under-abbrev-command,\nen/pull-do-not-rebase-after-fast-forwarding,\nen/sequencer-reflog-action, and en/rebase-no-keep-empty). Some or all\nof those topics might make sense to include in a stable release if\nyou're considering fixes other than security updates.\n\n> The protocol version change was painful for users that fetch in the\n> same repo from linux-next and other linux remotes[5]. The problem has\n> been isolated and fixed, so we could either apply the revert or apply\n> the fixes[6].\n>\n> credential helper hardening\n> ---------------------------\n> Lastly, after seeing a v2.26.1 security release and v2.26.2 security\n> release in quick succession, I'm looking at what it would take to make\n> Git more robust so we don't end up need .3, .4, .5 security releases\n> soon after. Perhaps we can make the credential system a bit more\n> robust to prevent future similar accidents. For example:\n>\n> - teach in-tree credential helpers to reject repeated fields in their\n> input (Just In Case some variant of newline injection that uses \\r\n> or something pops up)\n>\n> - teach in-tree credential helpers to require the host and protocol\n> fields to be set (e.g., [7])\n>\n> - update git-credential(1) to document the newly tightened protocol\n>\n> That might go against the goal of getting rid of excuses not to\n> upgrade, though. Where we see regression potential, we can be patient\n> and wait for 2.27, but if we have some examples with particularly low\n> regression potential then they might be okay 2.26.3 fodder as well.\n>\n> Thoughts?\n>\n> Thanks,\n> Jonathan\n>\n> [1] https://colabti.org/irclogger/irclogger_log/git-devel?date=2020-04-27#l65\n> [2] https://lore.kernel.org/git/20200426234750.40418-1-carenas@gmail.com/\n> [3] https://lore.kernel.org/git/pull.615.git.1587588665.gitgitgadget@gmail.com/\n> [4] https://lore.kernel.org/git/pull.620.git.1587767749.gitgitgadget@gmail.com/#t\n> [5] https://lore.kernel.org/git/20200422155047.GB91734@google.com/\n> [6] https://lore.kernel.org/git/cover.1588031728.git.jonathantanmy@google.com/\n> [7] https://lore.kernel.org/git/20200420224310.9989-1-carenas@gmail.com/\n"},{"id":"396478","messageId":"xmqq7dxz4j62.fsf@gitster.c.googlers.com","threadId":"53337","inReplyTo":"20200428055514.GB201501@google.com","subject":"proto v2 fixes for maint (was Re: Preparing for a Git 2.26.3 release)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-28T17:25:09Z","receivedAt":"2020-04-28T17:25:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Since then we've heard about a few related (non-security) regressions.\n> I'd like to avoid giving people an excuse not to upgrade, so this\n> morning[1] I promised a discussion of what I'd like to see in a 2.26.3\n> release to help with that.\n\nThanks for starting this. \n\nI'll have chances to comment on other areas you listed, but since\nI've answered on v2-proto stuff to somebody else already...\n\n> The protocol version change was painful for users that fetch in the\n> same repo from linux-next and other linux remotes[5]. The problem has\n> been isolated and fixed, so we could either apply the revert or apply\n> the fixes[6].\n\nThe demote patch hasn't even hit 'master'. \n\nMy preference is to merge the demotion down to 'master' and 'maint'\nwhile merging down this fix to 'next' and to 'master'.\n\nAnd immediately revert the demotion on 'master', which will make the\ntip of 'master' with v2 as the default, with \"this\" fix.\n\nThat way, those who want to help us polish the code further for the\nnext release would use v2 as default with the proposed fix for this\nbreakage and can hunt for other breakages in v2, while those on the\nmaintenance track (and v2.26.3 JNeider wants to see happen soon)\nwould revert to the original protocol as default.\n\nIn short, my preference is to ship 2.26.3 with the \"demote v2 from\ndefault\", and hopefully try 2.27 with \"v2 with negotiation fix\" and\nhope people won't find any other remaining glitches in 2.27. After\nthat, we may want to merge the negotiation fix down to 2.26.x track\nbut I am not comfortable merging it in a release on the maintenance\ntrack with the timeframe we seem to be talking about (i.e. a few\nweeks, presumably).\n\n\n\n"},{"id":"396486","messageId":"20200428201657.30467979@naga.burning-in.hell","threadId":"53337","inReplyTo":"xmqq7dxz4j62.fsf@gitster.c.googlers.com","subject":"Re: proto v2 fixes for maint (was Re: Preparing for a Git 2.26.3 release)","fromName":"Michal Suchánek","fromEmail":"msuchanek@suse.de","sentAt":"2020-04-28T18:16:57Z","receivedAt":"2020-04-28T18:17:01Z","isPatch":false,"sender":{"key":"msuchanek@suse.de","avatar":"https://avatars.githubusercontent.com/u/787652?v=4"},"body":"On Tue, 28 Apr 2020 10:25:09 -0700\nJunio C Hamano wrote:\n\n> Jonathan Nieder writes:\n> \n> > Since then we've heard about a few related (non-security) regressions.\n> > I'd like to avoid giving people an excuse not to upgrade, so this\n> > morning[1] I promised a discussion of what I'd like to see in a 2.26.3\n> > release to help with that. \n> \n> Thanks for starting this. \n> \n> I'll have chances to comment on other areas you listed, but since\n> I've answered on v2-proto stuff to somebody else already...\n> \n> > The protocol version change was painful for users that fetch in the\n> > same repo from linux-next and other linux remotes[5]. The problem has\n> > been isolated and fixed, so we could either apply the revert or apply\n> > the fixes[6]. \n> \n> The demote patch hasn't even hit 'master'. \n> \n> My preference is to merge the demotion down to 'master' and 'maint'\n> while merging down this fix to 'next' and to 'master'.\n\nI understand that this issue puts v2 protocol into question and you\nwant to go back to v0 as default. Why not merge the fixes for v2,\nthough? Even if it is not the default keeping it broken in maint does\nnot sound great.\n\nThanks\n\nMichal\n"},{"id":"396488","messageId":"xmqqd07r322c.fsf@gitster.c.googlers.com","threadId":"53337","inReplyTo":"xmqq7dxz4j62.fsf@gitster.c.googlers.com","subject":"Re: proto v2 fixes for maint (was Re: Preparing for a Git 2.26.3 release)","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-04-28T18:19:55Z","receivedAt":"2020-04-28T18:19:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> In short, my preference is to ship 2.26.3 with the \"demote v2 from\n> default\", and hopefully try 2.27 with \"v2 with negotiation fix\" and\n> hope people won't find any other remaining glitches in 2.27. After\n> that, we may want to merge the negotiation fix down to 2.26.x track\n> but I am not comfortable merging it in a release on the maintenance\n> track with the timeframe we seem to be talking about (i.e. a few\n> weeks, presumably).\n\nThe last part needs clarification. What I am hesitant is to merge\nonly the \"negotiation fix\" in 2.26.3 while keeping v2 the default.\nAs long as v2 is not the default with the \"demote\" patch, I am OK\nto have the \"negotiation fix\" in there, too.\n"},{"id":"396524","messageId":"20200429055659.GC42649@google.com","threadId":"53337","inReplyTo":"xmqq7dxz4j62.fsf@gitster.c.googlers.com","subject":"Re: proto v2 fixes for maint (was Re: Preparing for a Git 2.26.3 release)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2020-04-29T05:56:59Z","receivedAt":"2020-04-29T05:57:04Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n> Jonathan Nieder writes:\n\n>> The protocol version change was painful for users that fetch in the\n>> same repo from linux-next and other linux remotes[5]. The problem has\n>> been isolated and fixed, so we could either apply the revert or apply\n>> the fixes[6].\n>\n> The demote patch hasn't even hit 'master'.\n>\n> My preference is to merge the demotion down to 'master' and 'maint'\n> while merging down this fix to 'next' and to 'master'.\n>\n> And immediately revert the demotion on 'master', which will make the\n> tip of 'master' with v2 as the default, with \"this\" fix.\n\nYes, sounds good to me.\n\nBy the way, the diagnosis in the demotion patch\n\n Users fetching from linux-next and other kernel remotes are reporting\n that the limited ref advertisement causes negotiation to reach\n MAX_IN_VAIN, resulting in too-large fetches.\n\nturned out to be false, as Peff noticed. It wasn't due to the ref\nadvertisement but was due to the protocol v2 code's reimplementation\nof negotiation. It's probably not worth amending the commit message,\ngiven that it's already in \"next\"; we can correct the record in the\nrevert for 'master', which I should probably write during the day when\nI am less likely to make more errors.\n\nMichal Suchánek wrote:\n\n> Why not merge the fixes for v2,\n> though? Even if it is not the default keeping it broken in maint does\n> not sound great.\n\nYes, I like the \"demote and fix\" approach you're recommending.\n\nThanks,\nJonathan\n"},{"id":"397440","messageId":"xmqqk11mvzb4.fsf@gitster.c.googlers.com","threadId":"53337","inReplyTo":"20200428055514.GB201501@google.com","subject":"Re: Preparing for a Git 2.26.3 release","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-08T22:26:07Z","receivedAt":"2020-05-08T22:26:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Since then we've heard about a few related (non-security) regressions.\n> I'd like to avoid giving people an excuse not to upgrade, so this\n> morning[1] I promised a discussion of what I'd like to see in a 2.26.3\n> release to help with that.\n\nI will be pushing out an update to 'master' shortly, which merges\nmore than a handful of features that could go to 2.26.x track. We\nobviously won't be merging all of them in 2.26.3, so let me try to\ngive an excerpt from the draft release notes on the 'master' front.\n\nI did not limit the following list to the ones that are related to\nthe recent CVEs, but I excluded many of them to limit the size of\n2.26.3.\n\nPlease help to further shrink the scope of 2.26.3 by nominating ones\nthat should be omitted. The absolute minimum would be just the ones\nrelated to the credential, I guess.\n\n * Those fetching over protocol v2 from linux-next and other kernel\n repositories are reporting that v2 often fetches way too much than\n needed.\n (merge 11c7f2a30b jn/demote-proto2-from-default later to maint).\n\n * The upload-pack protocol v2 gave up too early before finding a\n common ancestor, resulting in a wasteful fetch from a fork of a\n project. This has been corrected to match the behaviour of v0\n protocol.\n (merge 2f0a093dd6 jt/v2-fetch-nego-fix later to maint).\n\n * The server-end of the v2 protocol to serve \"git clone\" and \"git\n fetch\" was not prepared to see a delim packets at unexpected\n places, which led to a crash.\n (merge cacae4329f jk/harden-protocol-v2-delim-handling later to maint).\n\n * The more aggressive updates to remote-tracking branches we had for\n the past 7 years or so were not reflected in the documentation,\n which has been corrected.\n (merge a44088435c pb/pull-fetch-doc later to maint).\n\n * We've left the command line parsing of \"git log :/a/b/\" broken for\n about a full year without anybody noticing, which has been\n corrected.\n (merge 0220461071 jc/missing-ref-store-fix later to maint).\n\n * Misc fixes for Windows.\n (merge 3efc128cd5 js/mingw-fixes later to maint).\n\n * Parsing the host part out of URL for the credential helper has been corrected.\n (merge 4c5971e18a jk/credential-parsing-end-of-host-in-URL later to maint).\n\n * Validation of push certificate has been made more robust against\n timing attacks.\n (merge 719483e547 bc/constant-memequal later to maint).\n\n * Raise the minimum required version of docbook-xsl package to 1.74,\n as 1.74.0 was from late 2008, which is more than 10 years old, and\n drop compatibility cruft from our documentation suite.\n (merge 3c255ad660 ma/doc-discard-docbook-xsl-1.73 later to maint).\n\n * The build procedure did not use the libcurl library and its include\n files correctly for a custom-built installation.\n (merge 0573831950 jk/build-with-right-curl later to maint).\n\n * Recent update to Homebrew used by macOS folks breaks build by\n moving gettext library and necessary headers.\n (merge a0b3108618 ds/build-homebrew-gettext-fix later to maint).\n\n * Error and verbose trace messages from \"git push\" did not redact\n credential material embedded in URLs.\n (merge d192fa5006 js/anonymise-push-url-in-errors later to maint).\n\n * Update the parser used for credential..\n configuration, to handle s with '/' in them correctly.\n (merge b44d0118ac bc/wildcard-credential later to maint).\n\n * Recent updates broke parsing of \"credential..\" where\n is not a full URL (e.g. [credential \"https://\"] helper = ...)\n stopped working, which has been corrected.\n (merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint).\n (merge cd93e6c029 js/partial-urlmatch later to maint).\n\n * With the recent tightening of the code that is used to parse\n various parts of a URL for use in the credential subsystem, a\n hand-edited credential-store file causes the credential helper to\n die, which is a bit too harsh to the users. Demote the error\n behaviour to just ignore and keep using well-formed lines instead.\n (merge c03859a665 cb/credential-store-ignore-bogus-lines later to maint).\n\n * The samples in the credential documentation has been updated to\n make it clear that we depict what would appear in the .git/config\n file, by adding appropriate quotes as needed..\n (merge 177681a07e jk/credential-sample-update later to maint).\n\n * The header on NetBSD brings in its own definition of\n hmac() function (eek), which conflicts with our own and unrelated\n function with the same name. Our function has been renamed to work\n around the issue.\n (merge 3013118eb8 cb/avoid-colliding-with-netbsd-hmac later to maint).\n\n"},{"id":"397448","messageId":"nycvar.QRO.7.76.6.2005090903560.56@tvgsbejvaqbjf.bet","threadId":"53337","inReplyTo":"xmqqk11mvzb4.fsf@gitster.c.googlers.com","subject":"Re: Preparing for a Git 2.26.3 release","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2020-05-09T07:07:55Z","receivedAt":"2020-05-09T11:27:41Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 8 May 2020, Junio C Hamano wrote:\n\n> * Recent updates broke parsing of \"credential..\" where\n> is not a full URL (e.g. [credential \"https://\"] helper = ...)\n> stopped working, which has been corrected.\n> (merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint).\n> (merge cd93e6c029 js/partial-urlmatch later to maint).\n\nAre you planning on also releasing, say, v2.23.4, with this fix? I ask\nbecause GitHub Desktop currently bundles Git v2.23.x, and while we fixed\nthe breakages on Windows, they are still present on macOS and Linux (for\ndetails, see https://github.com/desktop/desktop/issues/9597).\n\nThanks,\nDscho\n"},{"id":"397459","messageId":"xmqqwo5luj6r.fsf@gitster.c.googlers.com","threadId":"53337","inReplyTo":"nycvar.QRO.7.76.6.2005090903560.56@tvgsbejvaqbjf.bet","subject":"Re: Preparing for a Git 2.26.3 release","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2020-05-09T17:11:56Z","receivedAt":"2020-05-09T17:12:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 8 May 2020, Junio C Hamano wrote:\n>\n>> * Recent updates broke parsing of \"credential..\" where\n>> is not a full URL (e.g. [credential \"https://\"] helper = ...)\n>> stopped working, which has been corrected.\n>> (merge 9a121b0d22 js/partial-urlmatch-2.17 later to maint).\n>> (merge cd93e6c029 js/partial-urlmatch later to maint).\n>\n> Are you planning on also releasing, say, v2.23.4, with this fix?\n\nYes, some subset of the changes we will apply to 2.26.3 probably can\nbe backported down to older maintenance releases. \n\nOur usual policy is not to backport beyond two or three maintenance\ntracks unless it is a security fix, and because the current maint\ntrack is 2.26.x, which means 2.25.x and possibly 2.24.x series are\nthe oldest candidates.\n\nIf you think it makes sense to start the discussion to choose that\nabsolute minimum set, I am fine with that approach, too. The\npartial-urlmatch topic was designed to be usable with tracks as old\nas 2.17.x series, so I am OK to go a bit further back but if we are\nto do so, how far back should we as the upstream go back? I am OK\nto say we make the 2.23 series as the oldest for this round.\n\nAnd then if we were to draw the line there, what other changes in\nthe set do we want to include the 2.{23,24,25,26}.x maintenance\nreleases? That would certainly be a narrower subset than the list \nin the message you are responding to.\n\nThanks.\n\n\n\n\n"}]}