Workaround change of behaviour in git 2.38.1 for CVE-2022-39253.

[adelton]

By default, protocol.file.allow now defaults to user, preventing clones with symlinks.

https://github.blog/2022-10-18-git-security-vulnerabilities-announced/#cve-2022-39253

Starting off with this proposal to see what approach would be deemed the best.

[adelton]

Also reported in CPAN as https://rt.cpan.org/Ticket/Display.html?id=144889, and in Fedora as https://bugzilla.redhat.com/show_bug.cgi?id=2137877.

[adelton]

Adding this proposed patch made Fedora package build: https://koji.fedoraproject.org/koji/buildinfo?buildID=2084874

[coolo]

Thanks for the fix, picked it up for openSUSE

[eserte]

As older git versions may be patched, too (e.g. git 2.25.1 found in Ubuntu 20.04 also does not allow file protocol by default) I think it's best to make the configuration change unconditional without a git version check.

[eserte]

See eserte@e957384 for an alternative patch.

[ap]

Tl;dr: a check for either 2.12.0 or 1.7.2 makes the most sense, though no check at all also makes some sense; whereas a check for 2.38.1 is not a good idea.

Older git versions may be patched, too

That, plus (to spell this out explicitly) the fact the configuration override has no deleterious effect even if passed to an older Git which doesn’t have the 2.38.1 change of default. So there is a good reason to omit the check for 2.38.1, and no real reason reason to include it. (I would however add a comment to explain why the override is there, and that would mention 2.38.1.)

If there was to be a version check, it would make more sense to check for a version of Git which supports protocol.<name>.allow, which was added in git/git@f1762d7 and therefore first released in 2.12.0. Personally I think I would put a check for this particular version. However, again, it isn’t strictly necessary, because passing an unknown configuration option simply does nothing.

More strictly relevant might be that -c itself has not always been a supported switch in git: it was added in git/git@8b1fa77 and therefore first released in 1.7.2. Prior to that, any attempt to use git -c just yields “Unknown option: -c” and exit status 129.

[toddr]

Fixes failures on t/21-submodule.t