submodule-config: verify submodule names as paths
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 (among other things).
Let's sanity-check these names to avoid building a path that
can be exploited. There are two main decisions:
1. What should the allowed syntax be?
It's tempting to reuse verify_path(), since submodule
names typically come from in-repo paths. But there are
two reasons not to:
a. It's technically more strict than what we need, as
we really care only about breaking out of the
$GIT_DIR/modules/ hierarchy. E.g., having a
submodule named "foo/.git" isn't actually
dangerous, and it's possible that somebody has
manually given such a funny name.
b. Since we'll eventually use this checking logic in
fsck to prevent downstream repositories, it should
be consistent across platforms. Because
verify_path() relies on is_dir_sep(), it wouldn't
block "foo\..\bar" on a non-Windows machine.
2. Where should we enforce it? These days most of the
.gitmodules reads go through submodule-config.c, so
I've put it there in the reading step. That should
cover all of the C code.
We also construct the name for "git submodule add"
inside the git-submodule.sh script. This is probably
not a big deal for security since the name is coming
from the user anyway, but it would be polite to remind
them if the name they pick is invalid (and we need to
expose the name-checker to the shell anyway for our
test scripts).
This patch issues a warning when reading .gitmodules
and just ignores the related config entry completely.
This will generally end up producing a sensible error,
as it works the same as a .gitmodules file which is
missing a submodule entry (so "submodule update" will
barf, but "git clone --recurse-submodules" will print
an error but not abort the clone.
There is one minor oddity, which is that we print the
warning once per malformed config key (since that's how
the config subsystem gives us the entries). So in the
new test, for example, the user would see three
warnings. That's OK, since the intent is that this case
should never come up outside of malicious repositories
(and then it might even benefit the user to see the
message multiple times).
Credit for finding this vulnerability and the proof of
concept from which the test script was adapted goes to
Etienne Stalmans.
Affects: git < 2.13.7 and git < 2.14.4 and git < 2.15.2 and git < 2.16.4 and
git < 2.17.1
(From OE-Core rev: 229bb7cd70c79944d54696d50f4f34df85a5804a)
Signed-off-by: Jagadeesh Krishnanjanappa <jkrishnanjanappa@mvista.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add /usr/share/git-core/templates/hooks/fsmonitor-watchman.sample to PERLTOOLS to fix:
ERROR: git-2.16.1-r0 do_package_qa: QA Issue: /usr/share/git-core/templates/hooks/fsmonitor-watchman.sample contained in package git requires /usr/bin/perl, but no providers found in RDEPENDS_git? [file-rdeps]
ERROR: git-2.16.1-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
(From OE-Core rev: d8a93d75c75bf8df40f3e167eca2fcef4f76e240)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These git commands require Perl modules that do not exist in OE-Core.
Add PACKAGECONFIGs to enable them. Be aware though that if you enable
them you must also provide the missing dependencies.
(From OE-Core rev: d7909007b2a912ae5adf01edfabaa8b8646369cd)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Remove git-relink from PERLTOOLS:
git-2.13.2/Documentation/RelNotes/2.12.0.txt:
* An ancient script "git relink" has been removed.
(From OE-Core rev: f759420ad2a60d0be4ca15f4c9294086ecc86e59)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
(From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since commit set default libexecdir to $prefix/libexec
...
commit f35b2e29d9
Author: Ross Burton <ross.burton@intel.com>
Date: Tue Apr 30 20:35:54 2013 +0100
bitbake: set default libexecdir to $prefix/libexec
...
It casued '${D}${libdir}' does not exist, and the following
move operation incorrect which triggered QA Issue:
...
ERROR: git-2.7.0-r0 do_package: QA Issue: git: Files/directories were installed but not shipped in any package:
/usr/lib64
/usr/lib64/site_perl
/usr/lib64/site_perl/5.22.1
...
(From OE-Core rev: 2b82a475a7c8310f432b872e9d1e5eca262a03ee)
Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
With the autodebug package generation logic, specifically setting FILES_${PN}-dbg
isn't needed in most cases, we can remove them.
(From OE-Core rev: 3ab59d49dd7c18e194b58d1248b4b87709b5a738)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
There is no c_c99_format in configure, and there is no
ac_cv_c_c99_format in config.log after removed.
(From OE-Core rev: ef84b14ec0d1c7a7e5da278d8a4fe189806a1af2)
(From OE-Core rev: 41876e4bd4352081b80d47f9620bb5de7128971d)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Trying to use git w/o tab completion is especially annoying if
you are used to using it elsewhere -- "whatchanged" is simply
too annoying to type out in full more than once.
(From OE-Core rev: 3c5285237dece0af594e74926e6f4f02ca81f715)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
These could be created from scratch from git itself, but it
requires asciidoc, xsltproc, python bits and too much other
baggage. Since the git folks issue a tarball with the manpages
for each release, it is simpler to just go get that.
(From OE-Core rev: 9aba4bf2143c228d58aac06764f87ace5dd21d02)
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fixed when MACHINE = qemux86-64 and libdir = /usr/lib64:
mv: cannot stat `/path/to/image/usr/lib64/perl-native/perl': No such file or directory
The perl-native files are always installed to /usr/lib on both 32/64
bits targets.
(From OE-Core rev: fad6d25e548cb82c2106eb30ccdc0b8f3408de0a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Git perl tools such as add--interactive load the Git module at runtime.
A previous patch to eliminate a QA error by deleting it instead of
packaging it was incorrect.
beaglebone[62]$ git add -i
Can't locate Git.pm in @INC (you may need to install the Git module) (@INC contains: /usr/lib/perl/5.20.0 /prj/pab/Utils/lib/perl5/linux-arm/5.020000 /prj/pab/Utils/lib/perl5/ /prj/pab/Utils/lib/perl5/site_perl/linux-arm /prj/pab/Utils/lib/perl5/site_perl /etc/perl /usr/lib/perl/site_perl/5.20.0/ /usr/lib/perl/site_perl/5.20.0 /usr/lib/perl/vendor_perl/5.20.0/ /usr/lib/perl/vendor_perl/5.20.0 /usr/lib/perl/5.20.0/ /usr/local/lib/site_perl .) at /usr/lib/git/git-core/git-add--interactive line 7.
BEGIN failed--compilation aborted at /usr/lib/git/git-core/git-add--interactive line 7.
[YOCTO#3780]
(From OE-Core rev: 804f8e650f433d00907ec04282c22aaff2e5c044)
Signed-off-by: Peter A. Bigot <pab@pabigot.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Hardcoded paths to perl don't make sense, use from the environment instead.
[Patch taken from meta-mentor by RP]
(From OE-Core rev: 8072f26f7304ff5367d5be357037644cb1f6241e)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It seems that there are multiple problems with the upstream RUNTIME_PREFIX
mechanism at this time. It doesn't canonicalize argv[0] to an absolute path,
breaking calls via the PATH, for example. In addition, it doesn't seem to
locate template_dir via the runtime prefix even when specified as relative.
Revert this for now to the previous wrapper-based mechanism, but tweaked
slightly to avoid hardcoding the sysroot path into the wrapper (based on the
bits in the rpm recipe).
[YOCTO #6211]
[Pulled from meta-mentor by RP]
(From OE-Core rev: 85ce11e7b5402cc443adb8007c0e5d01f914fa74)
Signed-off-by: Christopher Larson <kergoth@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We need to pass CFLAGS and LDFLAGS to the makefile correctly so we
need to list them as part of EXTRA_OEMAKE.
We also have a problem where git hardlinks binaries in bindir with
those in its libexecdir. If we change the RPATH in one of them, it
breaks the other. We therefore set the no cross dir hardlinking flag
git already has for this kind of issue. This ensures the RPATHS for
the git-core binaries works correctly. Its pure luck this has
sometimes worked so far.
(From OE-Core rev: 64c6ae6a69215b659b82c67e238bc0fbc09a3eab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
References to "perl-native" were slipping into the target packages. These
changes ensure those references are cleaned up and that tools using perl
are packaged in the correct perltools package. The same issues affected
the nativesdk-git output so are also applied there.
[YOCTO #5918]
(From OE-Core rev: fd4a6b0cd275931e552cd23233c178e9ec54bdbb)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch goes through the OE-Core recipes and marks those which use autotools
but don't support a separate build directory (${S} != ${B}). A new class,
autotools-brokensep is used for this purpose.
This doesn't introduce any change in behaviour in its own right.
(From OE-Core rev: 006b8a7808a58713af16c326dc37d07765334b12)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Upgrade to 1.8.5.2
* Remove the SRC_URI from the git.inc since we use the one in
git_1.8.5.2.bb
(From OE-Core rev: 89e721830f2b2840d62e613c4bc89eca1fffd03a)
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
A lot of our recipes had short one-line DESCRIPTION values and no
SUMMARY value set. In this case it's much better to just set SUMMARY
since DESCRIPTION is defaulted from SUMMARY anyway and then the SUMMARY
is at least useful. I also took the opportunity to fix up a lot of the
new SUMMARY values, making them concisely explain the function of the
recipe / package where possible.
(From OE-Core rev: b8feee3cf21f70ba4ec3b822d2f596d4fc02a292)
Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
