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/
The USE_LIBPCRE setting now defaults to pcre2; use it. It's still
valid to set USE_LIBPCRE2, but using the default should be cleaner in
the long-run.
The (long-unmaintained) emacs support has been dropped upstream in favor
of better alternatives. From the upstream commit¹:
The git-blame.el mode has been superseded by Emacs's own
vc-annotate (invoked by C-x v g). Users of the git.el mode are now
much better off using either Magit or the Git backend for Emacs's own
VC mode.
These modes were added over 10 years ago when Emacs's own Git support
was much less mature, and there weren't other mature modes in the wild
or shipped with Emacs itself.
These days these modes have few if any users, and users of git aren't
well served by us shipping these (some OS's install them alongside git
by default, which is confusing and leads users astray).
¹ 6d5ed4836d ("git{,-blame}.el: remove old bitrotting Emacs code", 2018-04-11)
https://git.kernel.org/pub/scm/git/git.git/commit/?id=6d5ed4836d
Fixes two security issues, described in the 2.13.7 release notes¹:
* Submodule "names" come from the untrusted .gitmodules file, but we
blindly append them to $GIT_DIR/modules to create our on-disk repo
paths. This means you can do bad things by putting "../" into the
name. We now enforce some rules for submodule names which will cause
Git to ignore these malicious names (CVE-2018-11235).
Credit for finding this vulnerability and the proof of concept from
which the test script was adapted goes to Etienne Stalmans.
* It was possible to trick the code that sanity-checks paths on NTFS
into reading random piece of memory (CVE-2018-11233).
¹ https://mirrors.edge.kernel.org/pub/software/scm/git/docs/RelNotes/2.13.7.txt
The perl install process was updated to remove the need for
ExtUtils::MakeMaker. The main change for us is setting perllibdir to
keep the files installed in %{perl_vendorlib}.
Manpages for non-public portions of the Git perl modules are no longer
built. Anyone who wishes to make use of these modules can read the
source files or use pod2man.
Set NO_PERL_CPAN_FALLBACKS to ensure we don't package the bundled
fallback modules.
Also drop now-unneeded commands to remove *.bs, .packlist, and
perllocal.pod files. The new install method does not produce these
artifacts.
This release fixes an issue which only affects users on case-insensitive
file systems and repositories which contain paths that differ only in
case. Such circumstances result in a segmentation fault in various git
commands.
From the release announcement¹
A malicious third-party can give a crafted "ssh://..." URL to an
unsuspecting victim, and an attempt to visit the URL can result in
any program that exists on the victim's machine being executed.
Such a URL could be placed in the .gitmodules file of a malicious
project, and an unsuspecting victim could be tricked into running
"git clone --recurse-submodules" to trigger the vulnerability.
Credits to find and fix the issue go to Brian Neel at GitLab, Joern
Schneeweisz of Recurity Labs and Jeff King at GitHub.
¹ https://public-inbox.org/git/xmqqh8xf482j.fsf@gitster.mtv.corp.google.com/
EL-5 has been EOL for several months now. We can drop all the
conditionals needed to build there, as well as some conditionals for
long-expired Fedora releases.
Without EL-5 we also no longer use the prebuilt documentation. Remove
these sources and simplify the gpg check for the remaining source.
Many years ago, the GPG signature file was included in the source list¹.
A compromise at kernel.org caused the tarballs to move to googlecode.com
for a number of releases and the signatures were not provided in an
easily downloaded format². When the source location was moved back to
kernel.org, the signature file had already been removed from the spec
file and was not re-added³.
There is an effort underway to make GPG signature verification a
requirement when upstream provides signatures⁴. Regardless of whether
this becomes a requirement in the packaging guidelines, verification of
upstream signatures makes good sense. It also makes the process easier
for git package maintainers, who are (or should be ;) doing this
manually for each upstream git release.
While adding the signatures to the source list, all non-upstream source
files were moved to Source10 and above. This should make it easier to
add new upstream source files in the future, avoiding the need for
tedious (and error-prone) renumbering of existing sources.
Remove the unused entry for Patch14 also.
¹ ea3f253 Include gpg signature for tarball in SRPM (2011-08-26)
² c57f383 Update to 1.7.9.1 (2012-02-15)
³ b741f45 Change source URLs, as googlecode doesn't have up-to-date
tarballs (2014-06-10)
⁴ https://fedorahosted.org/fpc/ticket/610https://fedoraproject.org/wiki/PackagingDrafts:GPGSignatureshttps://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/2TBK4LLNRH73QJQSXWFPCQYHGTSJ3C7P/
Using https URL's for source files provides a little more security for
those downloading the code. Packagers, of course, should be verifying
the GPG signature files before pushing new releases to Fedora's source
cache¹.
While we're changing the source URL's, we might as well use the smaller
tar.xz files which upstream provides. (This requires minor adjustments
to the unpacking of prebuilt html and man tarballs; tar on el5 does not
know how to automatically filter via xz.)
¹ Replace .xz with .sign for the signatures, which are made against the
uncompressed tarballs.
- include git-credential-gnome-keyring helper in git pkg
- 0001-cvsimport-strip-all-inappropriate-tag-strings.patch was merged
Signed-off-by: Adam Tkac <atkac@redhat.com>
Use git-core.googlecode.com for source URL, as that's where Junio is
posting official tarballs now. The gpg signatures are now available on
that site in the comments for each tarball. For example, the signature
for 1.7.9.1 and download link can be found at:
http://code.google.com/p/git-core/downloads/detail?name=git-1.7.9.1.tar.gz&can=2&q=
This update fixes an incompatibility caused by the git push --quiet fix¹
included in 1.7.6.1. Unfortunately, the "fix" was reverted. A proper
fix for git push --quiet is being worked on for a future release.
Also worthy of note is that the source tarball for 1.7.6.2 is not
available due to the recent intrusion at kernel.org. Instead, the
tarball was generated using 'make dist' from the git tree. The v1.7.6.2
tag was verified using Junio's GPG key and compared against the 1.7.6.1
tarball to verify the diff.
¹ http://thread.gmane.org/gmane.comp.version-control.git/180652
- Fix conditionals for EL-6
- Comply with Emacs add-on packaging guidelines (#573423), Jonathan
Underwood
- Place elisp source files in separate emacs-git-el package
- Place git support files in own directory under site-lisp
- Use Emacs packaging macros
