Release notes:
https://github.com/git/git/raw/v2.28.0-rc0/Documentation/RelNotes/2.28.0.txt
Update git.skip-test-patterns to catch the 2GB clone test. The output
of the skipped test was changed (for the better) in upstream commit
d63ae31962 (t5608: avoid say() and use "skip_all" instead for
consistency, 2020-05-22).
From the upstream release notes¹:
With a crafted URL that contains a newline or empty host, or lacks
a scheme, the credential helper machinery can be fooled into
providing credential information that is not appropriate for the
protocol in use and host being contacted.
Unlike the vulnerability CVE-2020-5260 fixed in v2.17.4, the
credentials are not for a host of the attacker's choosing; instead,
they are for some unspecified host (based on how the configured
credential helper handles an absent "host" parameter).
The attack has been made impossible by refusing to work with
under-specified credential patterns.
¹ https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.17.5.txt
From the upstream release notes¹:
With a crafted URL that contains a newline in it, the credential
helper machinery can be fooled to give credential information for
a wrong host. The attack has been made impossible by forbidding
a newline character in any value passed via the credential
protocol.
¹ https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.17.4.txt
When the libsecret credential helper was split out in 9d91bab (split
libsecret credential helper into a subpackage (#1804741), 2020-02-19), a
few rpmlint errors & warnings crept in.
Update the rpmlintrc file to ignore the no-documentation warning for the
libsecret subpackage (replacing the gnome-keyring entry which is no
longer needed). Fix an errant tab added to the spec file.
Moving the libsecret credential helper to a subpackage left no binaries
in the main git package, so rpmlint complains. Fixing this requires a
bit more investigation and care.
Quoting from the upstream patch:
Jan Alexander Steffens reported that when `rebase.abbreviateCommands'
is set, the merge backend fails to fast forward. This is because the
backend generates a todo list with only a `noop', and since this
command has no abbreviated form, it is replaced by a comment mark.
The sequencer then interprets it as if there is nothing to do, and
fails.
References:
https://github.com/git/git/commit/68e7090f31https://lore.kernel.org/git/9b4bc756764d87c9f34c11e6ec2fc6482f531805.camel@gmail.com/
The workaround added in 9a7edd4 (work around issue on s390x with gcc10
(#1799408), 2020-02-22) is no loner needed. The issue is fixed in
gcc-10.0.1-0.9.
A recent change to the perl packaging split many modules from the base
perl-interpreter package. Add the missing test dependencies.
A few non-perl packages are also added, as they are no longer pulled
into the buildroot automatically, but were not properly required.
The make test call was changed to use %make_build in d34bc42 (Use
make_build macro when running tests, 2020-01-14) in order to allow the
options to be more easily overridden. This enabled the -O option by
default, which causes the test output to be printed only after all the
tests have run.
That makes following the progress in both interactive and copr/koji
builds difficult. Replace %make_build with %__make to drop the unwanted
-O option but still allow the make command to be overridden.
The Asciidoctor project is more actively maintained than asciidoc. Use
it for building the documentation on Fedora. Asciidoctor is not
currently available for EL-6 or EL-8, though it is in EPEL for EL-7.
Exclude all EL builds for now, until we can reliably use it on EL-7 and
EL-8 (including CentOS-Stream, ideally).
This is made possible by the excellent work of both the Git and
Asciidoctor communities. Thanks in particular to brian m. carlson,
Martin Ågren, Jeff King, and Dan Allen.
When git is built with gcc10 on s390x, the diff builtin fails many
tests. Use -mtune=zEC12 as a workaround until the issue is fixed
(in gcc and/or git).
Many thanks to Jakub Jelinek for doing the hard work to track this down.
The libsecret package added a weak dependency on gnome-keyring in
4976bb0 (Recommend gnome-keyring, 2019-09-06). This pulls in a bit more
than we would like with the git package. Move the libsecret credential
helper to a subpackage.
This will make it possible for buildroots to inject arguments to
make by redefining the %__make macro.
For example, the test target uses gcc to compile fuzz-commit-graph.c, so
one thing this change will allow us to do is to pass CC=clang to make if
we want to try to build with clang.
This `cat config.mak` was added in 37cec08 (Print config.mak to aid
confirmation/verification of settings, 2019-02-02). Replace it by
piping the earlier cat through tee so we get a copy of the config on
stdout as well as written to config.mak.
The highlight package is not available for aarch64 or s390x in EL7+.
Simplify the conditional (a little) by only listing the 2 known
architectures where highlight is available for EL7+. It's not worth
adding much complexity for a dependency that is only used in 3 tests
for the gitweb subpackage.
When upgrading or reinstalling git-daemon, the rpm %postun scriptlet
runs the %systemd_postun_with_restart macro with git@.service as the
argument. The macro calls 'systemctl try-restart git@.service' which
produces an error:
$ dnf -y update git-daemon
[...]
Running scriptlet: git-daemon-2.24.1-1.fc31.x86_64 2/2
Failed to try-restart git@.service: Unit name git@.service is missing the instance name.
See system logs and 'systemctl status git@.service' for details.
Until systemd-242, the error was hidden because the systemd scriptlets
directed all output to /dev/null. That was changed in systemd commit
b0ca726585 (rpm: avoid hiding errors from systemd commands, 2019-03-20),
exposing this bug in the git-daemon scriptlets.
The misconfiguration also leaves a stale symlink in /etc/systemd if
git.socket is enabled. Removing the git-daemon package and installing
again later results in git.socket being enabled.
Neither of these are the expected nor intended outcomes. Replace
git@.service with git.socket in the systemd scriptlets.
The issue was introduced in 906d847 (Rename git.service into
git@.service and bump release, 2014-10-24). It went unnoticed until now
largely because the systemd scriptlets hid their output.
This effectively reverts 8faf622 (drop jgit BR on Fedora > 30,
2019-07-29). The jgit package is available once again; use it to allow
some compatibility tests to be run.
Resolves: https://bugzilla.redhat.com/1766626
While this could arguably be a Recommends: rather than Requires:, we
chose the latter for a few reasons. The user experience when running
gitk and selecting "Start git gui" from the menu is quite poor. No
indication is shown to the user graphically. The only hint as to why
git gui did not start is output to stdout (and is not terribly helpful
for users who may be using gitk and git-gui because they are unfamiliar
with the command-line).
There are no additional dependencies pulled in by git-gui which are not
already dependencies of gitk. And the git-gui package is relatively
small.
Lastly, the default behavior of Recommends: is the same as Requires: at
this time.
If/when any of these things change, we may revisit whether moving to
Recommends: makes more sense.
Thanks to Vasiliy Glazov and Pavel Cahyna for reporting the issue and
helping to determine the proper resolution.
Adjust skipped test number in t5541-http-push-smart.sh (skipped on
aarch64, %{arm}, and %{power64}). A new test was added in upstream
6f1194246a ("remote-curl: pass on atomic capability to remote side",
2019-10-16), resulting in the "push 2000 tags over http" test number
changing.
Release notes:
https://www.kernel.org/pub/software/scm/git/docs/RelNotes/2.24.0.txt
With the move of java packages to modules, jgit looks likely to become
unavailable as a BuildRequires in Fedora soon. Avoid it on Fedora > 30
for now.
This affects 3 tests, 2 for packfile format (t5310-pack-bitmaps) and
1 of ls-remote (t5512-ls-remote).
"git <cmd> --git-completion-helper" could fail if the command checks for
a repo before parse_options(). If the result is cached, later on when
the user moves to a worktree with repo, tab completion will still fail.
Avoid this by detecting errors and not cache the completion output.
Running jgit on Fedora >= 30 results in an immediate failure¹:
$ jgit --version
/usr/bin/build-classpath: Could not find xz-java Java extension for this JVM
/usr/bin/build-classpath: error: Some specified jars were not found
Error: Could not find or load main class org.springframework.boot.loader.JarLauncher
Skip the jgit tests if 'jgit --version' fails. This way we'll begin
running them again once the issue is resolved -- without having to make
any further changes to the git package.
Also exclude jgit on i386 arch, as upstream eclipse has dropped support.
We could adjust the conditional to only exclude on Fedora >= 30 and
i386, but the added complexity is not worth the effort.
¹ jgit bug report: https://bugzilla.redhat.com/1709624
The git-gui Makefile does not follow the INSTALL_SYMLINKS setting.
Until it does, manually symlink git-citool to git-gui.
Test that the files are identical before linking, to avoid issues if
they begin to differ in the future.
The documentation tools respect these variables when generating dates in
the man and html docs. This is a small step toward making the package
builds reproducible.
An alternate method to set SOURCE_DATE_EPOCH would be to set the rpm
%source_date_epoch_from_changelog macro. Using the version file from
the tarball is a little nicer as the date is printed in the man pages.
We'd still need to set TZ anyway, as the html documentation sets the
'last updated' footer entry based on the timestamp of the corresponding
txt file.
[Note: It is possible to avoid the 'last updated' footer entirely by
setting the asciidoc footer-style attribute to none. This would need to
be done via sed or a patch, as there's not currently a way to set this
in config.mak -- but perhaps there should be.]
Reference: https://reproducible-builds.org/specs/source-date-epoch/
TEST_SHELL_PATH was added in 62f562d ("Use 'prove' as test harness,
enable shell tracing", 2018-01-18). Shortly afterward, upstream commit
a5bf824f3b ("t: prevent '-x' tracing from interfering with test helpers'
stderr", 2018-02-25)¹ removed the need to use bash to get the benefits of
running the test suite with '-x' tracing.
¹ https://github.com/git/git/commit/a5bf824f3b
The Makefiles for contrib/{contacts,subtree} don't include various
asciidoc, docbook, and xmlto options which are added to docs built from
the Documentation dir. Without these options the man page generated
for git-contacts has formatting issues.
Move the contrib/{contacts,subtree} docs to the Documentation dir to be
built along with the other doc files.
Now that Fedora 30 defaults to gnupg2 as /bin/gpg we don't need to
install gnupg for the test suite. We already require gnupg2 to verify
the source files.
Having the output of the config.mak file in the build output is very
convenient, particularly when building in koji or copr where it is not
possible to directly access the buildroot.
GnuPG2 requires gpg-agent and tries to start it on demand. The agent
uses a socket for communication and the path to this socket must be
shorter than sun_path [108 characters, per unix(7)].
Adjust the location of the temporary directories used by the test suite
by passing the --root option via GIT_TEST_OPTS.
One potential downside to this is that we use mktemp to create the
directory and this will differ between builds. If/when we want to make
our builds entirely reproducible we will need to revisit this. With
luck, gnupg will be better behaved by that time¹.
An alternate solution I tested was to rename the two problematic tests
(t5573 and t7612). This is a brittle solution as new tests may be added
which cause the same path length issue for gpg-agent.
Also drop the redundant killing of gpg-agent. This doesn't break
anything but it can only slow the test suite (however slightly).
¹ A ticket was filed to improve gpg-agent's handling of long paths in
GNUPGHOME (but it's nearly 2 years old): https://dev.gnupg.org/T2964.
In addition to the gnupg2-smime BR, patch an issue which prevents the
gpgsm tests from running. Only include gpgsm on Fedora and RHEL > 8.
On RHEL < 8 the gnupg2-smime package is too old to run the tests.
The test suite uses is_IS.UTF-8 and is_IS.ISO8859-1 (via the
GETTEXT_LOCALE and GETTEXT_ISO_LOCALE prereq's. Ensure these locales
are available. Installing glibc-langpack-is is insufficient as it does
not provide is_IS.ISO8859-1, glibc-all-langpacks is also needed.
Now that we're installing additional langpacks, update the macro name
which was added in a6a24cf ("Add glibc-langpack-en BuildRequires for
en_US.UTF-8 locale", 2018-11-05).
The pcre BR was added in 6dc6285 ("Improve test suite coverage",
2017-11-10), which seems to have been an oversight. The test suite
improvements were worked on over a long period of time. It is quite
likely that the pcre BR was needed before 6dc6285 was finalized.
Regardless, we began building against pcre2 in 595b682 ("Use pcre2
library", 2017-07-22).
Note that pcre remains in the minimal buildroot due to dependencies in
glib2 and grep.
When preparing the srpm in mock or other minimal environments, the use
of %{_emacs_version} causes a spurious warning:
Possible unexpanded macro in: Requires: emacs-filesystem >= %{_emacs_version}
Prevent the warning with a check that the macro is defined before use.
(There is another use of %{_emacs_version}, but it only applies to EL-6
where the warning is not present. Just ignore it.)
Make it easier to tell what %if conditions are being ended. This is
particularly useful with nested conditions since we lack any indentation
to visually denote the conditional blocks.
The %{without ...} macro is easier to read than '! %{with ...}', use it
consistently.
(Note that using %without_* and %_without_* macros is still not
advised.)
The verification was simplified slightly in 903d8f3 ("Remove EL-5 and
old Fedora conditionals", 2017-07-22).
Further simplifications:
- do away with unneeded variables
- drop '--batch' and '>/dev/null' from gpg2 --dearmor
- check tarball signature via stdin
The "noisy output from GnuPG 2.0" alluded to on EL <= 7 is no longer
present. This has been tested in mock for el6, el7, and fedora
releases.
The chroot is a bit quicker to create and slightly smaller when building
'--without tests' if the BuildRequires needed to run the tests are
skipped.
Add pod2man dependency when documentation is enabled (the default).
Since git-2.17.0, pod2man is needed to build Git.3pm. The pod2man
command is in perl-podlators on Fedora and EL >= 7, but in perl on EL-6.
Use %{_bindir}/pod2man to ensure the dependency is found regardless of
what package provides it.
The dependency is only missed when building without the test deps, as
the many perl requirements pulled in for the test suite bring in
pod2man.
From the upstream release announcement:
These releases fix a security flaw (CVE-2018-17456), which allowed an
attacker to execute arbitrary code by crafting a malicious .gitmodules
file in a project cloned with --recurse-submodules.
When running "git clone --recurse-submodules", Git parses the supplied
.gitmodules file for a URL field and blindly passes it as an argument
to a "git clone" subprocess. If the URL field is set to a string that
begins with a dash, this "git clone" subprocess interprets the URL as
an option. This can lead to executing an arbitrary script shipped in
the superproject as the user who ran "git clone".
In addition to fixing the security issue for the user running "clone",
the 2.17.2, 2.18.1 and 2.19.1 releases have an "fsck" check which can
be used to detect such malicious repository content when fetching or
accepting a push. See "transfer.fsckObjects" in git-config(1).
Credit for finding and fixing this vulnerability goes to joernchen
and Jeff King, respectively.
References:
https://public-inbox.org/git/xmqqy3bcuy3l.fsf@gitster-ct.c.googlers.com/
