Opening a file in binary mode and iterating it seems like the simple solution
but will still break on newlines, which for binary files isn't really useful as
the size of the chunks could be huge or tiny.
Instead, let's be a bit more clever: we'll be MD5ing lots of files, but we don't
want to fill up memory: use mmap() to open the file and read the file in 8k
blocks.
(Bitbake rev: 41e6161c8ce8cc90ebc93d72852673ae60fac923)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The actual dependency on native Python and is handled by inheriting
python3native
(From OE-Core rev: 115a6dea664c9b18fd19b79659029afb52b1a660)
(From OE-Core rev: 82b018956763bf85b90d512c8a6bc96d59fa67fd)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(perl #131844) fix various space calculation issues in
pp_pack.c
- for the originally reported case, if the start/cur pointer is in the
top 75% of the address space the add (cur) + glen addition would
overflow, resulting in the condition failing incorrectly.
- the addition of the existing space used to the space needed could
overflow, resulting in too small an allocation and a buffer overflow.
- the scaling for UTF8 could overflow.
- the multiply to calculate the space needed for many items could
overflow.
For the first case, do a space calculation without making new pointers.
For the other cases, detect the overflow and croak if there's an
overflow.
Originally this used Size_t_MAX as the maximum size of a memory
allocation, but for -DDEBUGGING builds realloc() throws a panic for
allocations over half the address space in size, changing the error
reported for the allocation.
For non-DEBUGGING builds the Size_t_MAX limit has the small chance
of finding a system that has 3GB of contiguous space available, and
allocating that space, which could be a denial of servce in some cases.
Unfortunately changing the limit to half the address space means that
the exact case with the original issue can no longer occur, so the
test is no longer testing against the address + length issue that
caused the original problem, since the allocation is failing earlier.
One option would be to change the test so the size request by pack is
just under 2GB, but this has a higher (but still low) probability that
the system has the address space available, and will actually try to
allocate the memory, so let's not do that.
Note: changed
plan tests => 14713;
to
plan tests => 14712;
in a/t/op/pack.t
to apply this patch on perl 5.24.1.
Affects perl < 5.26.2
(From OE-Core rev: 0542779d2f1a8977a732800a8998fd88971c0c1d)
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>
(perl #132227) restart a node if we change to uni rules within the node and encounter...
This could lead to a buffer overflow.
(cherry picked from commit a02c70e35d1313a5f4e245e8f863c810e991172d)
Affects perl >= 5.18 && perl <= 5.26
(From OE-Core rev: 109ffd1b3d10753bfd711a14ad59b194ca3ce831)
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>
* CVE-2018-6798-1
The proximal cause is several instances in regexec.c of the code
assuming that the input was valid UTF-8, whereas the input was too short
for what the start byte claimed it would be.
I grepped through the core for any other similar uses, and did not find
any.
(cherry picked from commit fe7d8ba0a1bf567af8fa8fea128e2b9f4c553e84)
* CVE-2018-6798-2
The first patch for 132063 prevented the buffer read overflow when
dumping the warning but didn't fix the underlying problem.
The next change treats the supplied buffer correctly, preventing the
non-UTF-8 SV from being treated as UTF-8, preventing the warning.
(cherry picked from commit 1e8b61488f195e1396aa801c685340b156104f4f)
Affects perl >= 5.22 && perl <= 5.26
(From OE-Core rev: 4aaf09b9d657b1c2df85bf509008beacd6a00342)
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>
qga: check bytes count read by guest-file-read
While reading file content via 'guest-file-read' command,
'qmp_guest_file_read' routine allocates buffer of count+1
bytes. It could overflow for large values of 'count'.
Add check to avoid it.
Affects qemu < v3.0.0
(From OE-Core rev: a11c8ee86007f7f7a34b9dc29d01acc323b71873)
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>
* CVE-2018-1000030-1
[2.7] bpo-31530: Stop crashes when iterating over a file on multiple threads
* CVE-2018-1000030-2
Multiple threads iterating over a file can corrupt the file's internal readahead
buffer resulting in crashes. To fix this, cache buffer state thread-locally for
the duration of a file_iternext call and only update the file's internal state
after reading completes.
No attempt is made to define or provide "reasonable" semantics for iterating
over a file on multiple threads. (Non-crashing) races are still
present. Duplicated, corrupt, and missing data will happen.
This was originally fixed by 6401e56, which
raised an exception from seek() and next() when concurrent operations were
detected. Alas, this simpler solution breaks legitimate use cases such as
capturing the standard streams when multiple threads are logging.
Affects python <= 2.7.14
(From OE-Core rev: 4b6c84e0f950f839bfb8c40f197197f838d8b733)
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>
proc/readproc.c: Fix bugs and overflows in file2strvec().
Note: this is by far the most important and complex patch of the whole
series, please review it carefully; thank you very much!
For this patch, we decided to keep the original function's design and
skeleton, to avoid regressions and behavior changes, while fixing the
various bugs and overflows. And like the "Harden file2str()" patch, this
patch does not fail when about to overflow, but truncates instead: there
is information available about this process, so return it to the caller;
also, we used INT_MAX as a limit, but a lower limit could be used.
The easy changes:
- Replace sprintf() with snprintf() (and check for truncation).
- Replace "if (n == 0 && rbuf == 0)" with "if (n <= 0 && tot <= 0)" and
do break instead of return: it simplifies the code (only one place to
handle errors), and also guarantees that in the while loop either n or
tot is > 0 (or both), even if n is reset to 0 when about to overflow.
- Remove the "if (n < 0)" block in the while loop: it is (and was) dead
code, since we enter the while loop only if n >= 0.
- Rewrite the missing-null-terminator detection: in the original
function, if the size of the file is a multiple of 2047, a null-
terminator is appended even if the file is already null-terminated.
- Replace "if (n <= 0 && !end_of_file)" with "if (n < 0 || tot <= 0)":
originally, it was equivalent to "if (n < 0)", but we added "tot <= 0"
to handle the first break of the while loop, and to guarantee that in
the rest of the function tot is > 0.
- Double-force ("belt and suspenders") the null-termination of rbuf:
this is (and was) essential to the correctness of the function.
- Replace the final "while" loop with a "for" loop that behaves just
like the preceding "for" loop: in the original function, this would
lead to unexpected results (for example, if rbuf is |\0|A|\0|, this
would return the array {"",NULL} but should return {"","A",NULL}; and
if rbuf is |A|\0|B| (should never happen because rbuf should be null-
terminated), this would make room for two pointers in ret, but would
write three pointers to ret).
The hard changes:
- Prevent the integer overflow of tot in the while loop, but unlike
file2str(), file2strvec() cannot let tot grow until it almost reaches
INT_MAX, because it needs more space for the pointers: this is why we
introduced ARG_LEN, which also guarantees that we can add "align" and
a few sizeof(char*)s to tot without overflowing.
- Prevent the integer overflow of "tot + c + align": when INT_MAX is
(almost) reached, we write the maximal safe amount of pointers to ret
(ARG_LEN guarantees that there is always space for *ret = rbuf and the
NULL terminator).
Affects procps-ng < 3.3.15
(From OE-Core rev: 82d873a1b73da25ae415afe0e6203693f78b88c9)
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>
newgidmap: enforce setgroups=deny if self-mapping a group
This is necessary to match the kernel-side policy of "self-mapping in a
user namespace is fine, but you cannot drop groups" -- a policy that was
created in order to stop user namespaces from allowing trivial privilege
escalation by dropping supplementary groups that were "blacklisted" from
certain paths.
This is the simplest fix for the underlying issue, and effectively makes
it so that unless a user has a valid mapping set in /etc/subgid (which
only administrators can modify) -- and they are currently trying to use
that mapping -- then /proc/$pid/setgroups will be set to deny. This
workaround is only partial, because ideally it should be possible to set
an "allow_setgroups" or "deny_setgroups" flag in /etc/subgid to allow
administrators to further restrict newgidmap(1).
We also don't write anything in the "allow" case because "allow" is the
default, and users may have already written "deny" even if they
technically are allowed to use setgroups. And we don't write anything if
the setgroups policy is already "deny".
Ref: https://bugs.launchpad.net/ubuntu/+source/shadow/+bug/1729357
Fixes: CVE-2018-7169
Affects shadow <= 4.5
(From OE-Core rev: a875522540372a4fa6658885692e564dfd729f54)
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>
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>
CVE-2017-18018-1:
doc: clarify chown/chgrp --dereference defaults
* doc/coreutils.texi: the documentation for the --dereference
flag of chown/chgrp states that it is the default mode of
operation. Document that this is only the case when operating
non-recursively.
CVE-2017-18018-2:
doc: warn about following symlinks recursively in chown/chgrp
In both chown and chgrp (which shares its code with chown), operating
on symlinks recursively has a window of vulnerability where the
destination user or group can change the target of the operation.
Warn about combining the --dereference, --recursive, and -L flags.
* doc/coreutils.texi (warnOptDerefWithRec): Add macro.
(node chown invocation): Add it to --dereference and -L.
(node chgrp invocation): Likewise.
Affects coreutils <= 8.29
(From OE-Core rev: a523bc6a2ff7d5b5415a789de02fb055ccd2c077)
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>
double64_init: Check psf->sf.channels against upper bound
This prevents division by zero later in the code.
While the trivial case to catch this (i.e. sf.channels < 1) has already
been covered, a crafted file may report a number of channels that is
so high (i.e. > INT_MAX/sizeof(double)) that it "somehow" gets
miscalculated to zero (if this makes sense) in the determination of the
blockwidth. Since we only support a limited number of channels anyway,
make sure to check here as well.
CVE-2017-14634
Closes: #318
Affects libsndfile1 = 1.0.28
(From OE-Core rev: 00da7bad24cf78c9dba091b9e480515f25886b48)
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>
sfe_copy_data_fp: check value of "max" variable for being normal
and check elements of the data[] array for being finite.
Both checks use functions provided by the <math.h> header as declared
by the C99 standard.
Fixes#317
CVE-2017-14245
CVE-2017-14246
Affects libsndfile1 = 1.0.28
(From OE-Core rev: 39b1dc89ce2870d1a2630b2319783a6203cbcb08)
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>
Patch original c_rehash script with Debian patch instead
of overriding it with own version.
Error output from c_reshah without patching:
Unknown regexp modifier "/b" at ./c_rehash line 15, at end of line
Unknown regexp modifier "/W" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/3" at ./c_rehash line 28, at end of line
Unknown regexp modifier "/2" at ./c_rehash line 28, at end of line
No such class installdir at ./c_rehash line 63, near "Prefix our
installdir"
(Might be a runaway multi-line // string starting on line 28)
syntax error at ./c_rehash line 63, near "Prefix our installdir"
Can't redeclare "my" in "my" at ./c_rehash line 68, near ""
Execution of ./c_rehash aborted due to compilation errors.
(From OE-Core rev: f8a826f497073533a3e4c390255ae197d65d6ef3)
(From OE-Core rev: 4524d1f916b55db6d280ff51a41933b8ec9046b0)
Signed-off-by: Andrej Valek <andrej.valek@siemens.com>
Signed-off-by: Marko Peter <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The perlpath.pl script is used to patch the #! lines in all perl
scripts in the utils directory. However, as these scripts are run via
e.g. "perl foo.pl", they don't actually rely on the #! path to be
correct (which can be confirmed by the observation that the path is
currently being set to ${STAGING_BINDIR_NATIVE}/perl, which doesn't
exist).
(From OE-Core rev: ba88fe46d47846042518a5a1017d782ba548202c)
(From OE-Core rev: 1b0dcca0f083081295f32f09b408ab6c6c10f66f)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The openssl Configure script will only select standalone makedepend
(vs running "$CC -M") when building with gcc < 3.x or with an Apple
Xcode version which predates the switch to clang (in approx 2010?).
Neither of these cases are possible when building under OE, therefore
the dependency on makedepend-native can be dropped (ie align the
openssl 1.0 recipe with the 1.1 recipe, which has dropped the
makedepend-native dependency already).
(From OE-Core rev: 4c5bd69e5cb203c8a4c2f3716c941661c0afc830)
(From OE-Core rev: 74524ec2a0f5a4210dd6680afb4b685a69f96a71)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Openssl 1.1 requires perl in order to build (just as openssl 1.0
does). The missing dependency has gone unnoticed up to now since
hostperl-runtime-native is included in ASSUME_PROVIDED.
(From OE-Core rev: ed5f8bb582453e7d8a1636ad1463380076209bd2)
(From OE-Core rev: 33a9519040b6e5cd9e83bb76589f75b00f1cd1c2)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Squash whitespace in CC_INFO to avoid recipe whitespace changes to
CFLAG affecting the final openssl binaries (the value of CC_INFO gets
embedded in libcrypto, via buildinf.h).
(From OE-Core rev: 2227c51896d4399daac9d85f40d7510b7c8ae03f)
(From OE-Core rev: 0bda7fda8ce11b9b8c4c69aee1afbda30c3eadd5)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Creating the openssl manpages, which happens as part of do_install(),
can take a significant amount of time (e.g. ~50 seconds on a quad
core laptop). Provide a PACKAGECONFIG option to allow creation of the
manpages to be skipped completely if not required and inherit the
manpages class to automatically control the PACKAGECONFIG option
(based on the "api-documentation" distro feature).
(From OE-Core rev: 1ddca1872f64c566fd812a6ec44f2d4e4d84f58f)
(From OE-Core rev: 061c17ff22f4df573bccbf4b66f2fdf5501c3617)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The fact that the darwin support only appears to consider x86 (and
not x86_64) suggests that it's not maintained or tested. In general
oe-core doesn't support building on darwin.
(From OE-Core rev: 9c7f37bb1345c38211acd137c00b9d07f92601a7)
(From OE-Core rev: ebe53ed0e34b88c7d7fef22e1a5ad4959517fdab)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Previously (when EXTRA_OEMAKE contained -e) exporting these variables
over-rode default values in the top-level openssl Makefile. However,
since -e was removed from EXTRA_OEMAKE as part of:
http://git.openembedded.org/openembedded-core/commit/?id=537a404cfbb811fcb526cdb5f2e059257de6ef13
exporting these variables does nothing. The comment from that commit
that only AR is affected by removing -e wasn't correct, but the
effects of letting the openssl Makefile also control AS, EX_LIBS and
DIRS seem to be either benign or beneficial.
Since without -e make ignores DIRS from the environment and always
runs for all subdirs (including "test"), adding "test" to DIRS and
calling "make depend" again from do_compile_ptest() can be dropped.
(From OE-Core rev: b3e81e3cf86dd8736b62a6b88d6a6dbe518c9e5e)
(From OE-Core rev: 8aa33c15b7c71cda8de3e3571879a5d39c915adb)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This patch adds a second line to the -help output of the CA.pl script
(which lists almost the same command line options as the line above
it but in a slightly different order). Although it's tagged as a
Debian backport, there's no patch like it in recent Debian patch sets
for openssl 1.0.2.
(From OE-Core rev: 9b3af406747a3d565d12d948400d44fb12ab0d96)
(From OE-Core rev: 4a136f8b2cfb6cdd5ba16a2ebbe9b418fead1c76)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix inconsistent indent (and also make the openssl 1.1 recipe more
consistent and consistent with the openssl 1.0 recipe).
(From OE-Core rev: 69844643aa1b829c27f144db634c8223c18c783f)
(From OE-Core rev: 3e0290b51da404761ac6a7d2657fd10693bf21b9)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Currently target builds call make twice as part of do_compile(). It
appears to be an accidental side effect of needing to only pass
CC_INFO on the make command line for target builds, since CC_INFO is
only referenced by the reproducible build patches.
(From OE-Core rev: 6c4942b5c771876ad0e62e56923f59cc71776157)
(From OE-Core rev: 1aaca6b00c083eba25eb8502bbdffef4e45fafd8)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Since openssl isn't an autotools recipe, defining cryptodev-linux
related config options via PACKAGECONFIG hasn't worked correctly
since PACKAGECONFIG_CONFARGS stopped being automatically appended to
EXTRA_OECONF in 2016:
http://git.openembedded.org/openembedded-core/commit/?id=c98fb5f5129e71829ffab4449b3d28082bc95ab4
The issue appears to have been hidden as the flags are also hardcoded
in CFLAG - and therefore always enabled, regardless of the state of
the PACKAGECONFIG option. Fix by passing both EXTRA_OECONF and
PACKAGECONFIG_CONFARGS when running the openssl Configure script.
Although the openssl 1.1 recipe doesn't contain any PACKAGECONFIG
options yet, pre-emptively make the same fix there too.
Also only enable cryptodev-linux by default for target builds (based
on the historical comments in the recipe, that seems to have been the
original intention).
(From OE-Core rev: 6fee11b04b979a5b3237902d947db7118cafca2b)
(From OE-Core rev: 201f4a889c0e4b3d13369e38662bf97ed8a9a8e1)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop redundant setting of S to its default value, fix inconsistent
indent and re-order variables to align more closely to the OE
style-guide.
(From OE-Core rev: c36637a0304551bf2736bb15796947d9aaf00076)
(From OE-Core rev: 67cde33115798b298f7840cad34d8ef91b3b7fa2)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The openssl10.inc include file only has one user, so we can improve
maintainability by merging the include file into the recipe which
uses it.
(From OE-Core rev: f5568740d5ff72090c3ca894ddfdc3078169da25)
(From OE-Core rev: 5b4ffcbcdc28aec506a21f5abd76848c1de24011)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Drop redundant setting of S to its default value and re-order
variables to align more closely to the OE style-guide.
(From OE-Core rev: 4871481e66449dd2b054119b37d0baedb166b72c)
(From OE-Core rev: 5da668175ee7c56067c1272e7a701d5c38e94524)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Using += with an over-ride can be a source of confusion so try to
avoid the construct in core recipes.
The current usage is incorrect and prevents the aarch64 and musl
specific config options from being active together.
(From OE-Core rev: 2a30a9ecab6465892698f7fc9d14a430d8a26f0c)
(From OE-Core rev: 000da57cc858f5432153be849faba3862e4e9ed5)
Signed-off-by: Andre McCurdy <armccurdy@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When SDK is not installed in the default location, openssl will not be
able to find the the openssl.cnf config file:
"WARNING: can't open config file: XXXX/usr/lib/ssl/openssl.cnf"
To fix this, we need to provide the environment variable $OPENSSL_CONF
pointing to the correct config file location.
(From OE-Core rev: b3f148333515efdb746b78c57d62cfbf3321b21e)
(From OE-Core rev: fcea508efedeb36ca31fe8ad0cbc6d194fcfd1f7)
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
ccache and openssl don't get on:
| make[1]: Entering directory '/home/prj/yocto/build/tmp/work/core2-64-poky-linux/openssl/1.0.2o-r0/openssl-1.0.2o/crypto'
| ccache: invalid option -- 'D'
Disable the use of ccache in the openssl recipe until someone root-causes this.
[ YOCTO #12810 ]
(From OE-Core rev: 8f9ceebb197dba10f2d08449de2dd64584de06bb)
(From OE-Core rev: e90da34e5667acacd9ad0dd167846a6126fefad2)
Signed-off-by: Ross Burton <ross.burton@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Cleans up the packaging by moving libasound.so.2 back into the alsa-lib
package which was previously empty.
Previously, it was difficult to create an image that had libasound.so.2,
then create an SDK from that image that had the proper development
files, because the only way to get libasound.so.2 was to do:
IMAGE_INSTALL += "libasound"
This however caused a problem because all of the development files that
would be desired in the SDK were located in alsa-lib-dev, which wouldn't
be included because alsa-lib wasn't included, and it was impossible to
include alsa-lib because it was an empty package that was culled.
(From OE-Core rev: 6c3438a62d10f155cd6a391bdb2f1939fc4774ec)
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 30352f3d84)
Change-Id: I2fb065b7e00569ba3a6aac631ac863999455bfb2
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
