2018-02-14 12:13:51 +01:00
|
|
|
################################################################################
|
|
|
|
|
#
|
|
|
|
|
# libgit2
|
|
|
|
|
#
|
|
|
|
|
################################################################################
|
|
|
|
|
|
package/libgit2: security bump to version 0.28.4
Fixes the following CVE:
- CVE-2019-1351: Windows provides the ability to substitute
drive letters with arbitrary letters, including multi-byte
Unicode letters. To fix any potential issues arising from
interpreting such paths as relative paths, we have extended
detection of DOS drive prefixes to accomodate for such cases.
- CVE-2019-1352: by using NTFS-style alternative file streams for
the ".git" directory, it is possible to overwrite parts of the
repository. While this has been fixed in the past for Windows,
the same vulnerability may also exist on other systems that
write to NTFS filesystems. We now reject any paths starting
with ".git:" on all systems.
- CVE-2019-1353: by using NTFS-style 8.3 short names, it was
possible to write to the ".git" directory and thus overwrite
parts of the repository, leading to possible remote code
execution. While this problem was already fixed in the past for
Windows, other systems accessing NTFS filesystems are
vulnerable to this issue too. We now enable NTFS protecions by
default on all systems to fix this attack vector.
- CVE-2019-1354: on Windows, backslashes are not a valid part of
a filename but are instead interpreted as directory separators.
As other platforms allowed to use such paths, it was possible
to write such invalid entries into a Git repository and was
thus an attack vector to write into the ".git" dierctory. We
now reject any entries starting with ".git" on all systems.
libgit2 is not affected by these git CVE:
- CVE-2019-1348: the fast-import stream command "feature
export-marks=path" allows writing to arbitrary file paths.
- CVE-2019-1349: by using NTFS 8.3 short names, backslashes or
alternate filesystreams, it is possible to cause submodules to
be written into pre-existing directories during a recursive
clone using git.
- CVE-2019-1350: recursive clones may lead to arbitrary remote
code executing due to improper quoting of command line
arguments.
- CVE-2019-1387: it is possible to let a submodule's git
directory point into a sibling's submodule directory, which may
result in overwriting parts of the Git repository and thus lead
to arbitrary command execution. As libgit2 doesn't provide any
way to do submodule clones natively, it is not susceptible to
this vulnerability. Users of libgit2 that have implemented
recursive submodule clones manually are encouraged to review
their implementation for this vulnerability.
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-12-16 12:53:59 +01:00
|
|
|
LIBGIT2_VERSION = 0.28.4
|
package: remove 'v' prefix from github-fetched packages
On Github, a large number of projects name their tag vXYZ (i.e v3.0,
v0.1, etc.). In some packages we do:
<pkg>_VERSION = v0.3
<pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
And in some other packages we do:
<pkg>_VERSION = 0.3
<pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
I.e in one case we consider the version to be v0.3, in the other case
we consider 0.3 to be the version.
The problem with v0.3 is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix" and using
that they drop the "v" prefix for the version.
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org because Buildroot has 'v0.3'
and release-monitoring.org has '0.3'.
Since really the version number of 0.3, is makes sense to update our
packages to drop this 'v'.
This commit only addresses the (common) case of github packages where
the prefix is simply 'v'. Other cases will be handled by separate
commits. Also, there are a few cases that couldn't be handled
mechanically that aren't covered by this commit.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
[Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite,
python-scapy3k, softether]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
2019-06-12 08:42:06 +02:00
|
|
|
LIBGIT2_SITE = $(call github,libgit2,libgit2,v$(LIBGIT2_VERSION))
|
2018-02-14 12:13:51 +01:00
|
|
|
LIBGIT2_LICENSE = GPL-2.0 with linking exception
|
|
|
|
|
LIBGIT2_LICENSE_FILES = COPYING
|
|
|
|
|
LIBGIT2_INSTALL_STAGING = YES
|
|
|
|
|
|
|
|
|
|
LIBGIT2_CONF_OPTS = \
|
|
|
|
|
-DUSE_GSSAPI=OFF \
|
|
|
|
|
-DBUILD_CLAR=OFF \
|
|
|
|
|
-DUSE_ICONV=ON \
|
|
|
|
|
-DTHREADSAFE=$(if $(BR2_TOOLCHAIN_HAS_THREADS),ON,OFF)
|
|
|
|
|
|
2018-06-01 17:41:58 +02:00
|
|
|
LIBGIT2_DEPENDENCIES = zlib
|
|
|
|
|
|
2018-02-14 12:13:51 +01:00
|
|
|
# If libiconv is available (for !locale toolchains), then we can use
|
|
|
|
|
# it for iconv support. Note that USE_ICONV=ON is still correct even
|
|
|
|
|
# without libiconv because (1) most toolchain have iconv support
|
|
|
|
|
# without libiconv and (2) even if USE_ICONV=ON but iconv support is
|
|
|
|
|
# not available, libgit2 simply avoids using iconv.
|
|
|
|
|
ifeq ($(BR2_PACKAGE_LIBICONV),y)
|
|
|
|
|
LIBGIT2_DEPENDENCIES += libiconv
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_PACKAGE_LIBSSH2),y)
|
|
|
|
|
LIBGIT2_DEPENDENCIES += libssh2
|
|
|
|
|
LIBGIT2_CONF_OPTS += -DUSE_SSH=ON
|
|
|
|
|
else
|
|
|
|
|
LIBGIT2_CONF_OPTS += -DUSE_SSH=OFF
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(BR2_PACKAGE_OPENSSL),y)
|
|
|
|
|
LIBGIT2_DEPENDENCIES += openssl
|
2018-06-01 17:41:59 +02:00
|
|
|
LIBGIT2_CONF_OPTS += -DUSE_HTTPS=OpenSSL
|
2018-02-14 12:13:51 +01:00
|
|
|
else
|
2018-06-01 17:41:59 +02:00
|
|
|
LIBGIT2_CONF_OPTS += -DUSE_HTTPS=OFF
|
2018-02-14 12:13:51 +01:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
$(eval $(cmake-package))
|