Matching of hosts against proxy patterns can improperly treat an IPv6 zone ID
as a hostname component. For example, when the NO_PROXY environment variable
is set to "*.example.com", a request to "[::1%25.example.com]:80` will incorrectly
match and not be proxied.
(From OE-Core rev: 88e79f915137edc5a37a110abdc79f5800404e45)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Use the same sed command to sanitize libtool script for target recipe
and nativesdk one. Otherwise fails with buildpaths QA error:
ERROR: nativesdk-libtool-2.5.0-r0 do_package_qa: QA Issue: File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/usr/bin/libtool in package nativesdk-libtool contains reference to TMPDIR [buildpaths]
(From OE-Core rev: f08df9adf290fb6cbebff24df6bbbbe8e5ce95e0)
Upstream-Status: Backport[https://git.yoctoproject.org/poky/commit/?id=89e184da6c9d95a99fd34334df5ac6c5ae87f13a]
(From OE-Core rev: a720df7ad77af1f8b1c00a211c88537e5f23edbc)
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 89e184da6c)
Signed-off-by: Nikhil R <nikhilr5@kpit.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Since target and cross variants were already doing similar cleanup
of include-fixed headers, as those aren't used, unify the code and
also apply the same to cross-canadian variant.
Some of those header files get processed with a tool that leaves
absolute buildpaths inside the file's commented section, causing
QA errors. Since those aren't used, let's remove them.
This may be a temporary solution until the tool itself gets fixed
to not embed absolute buildpaths in the header files:
https://lists.openembedded.org/g/openembedded-core/topic/107268307
(From OE-Core rev: 621e0ac9308cc163fb767a27d63fff6570896b92)
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This patch is causing build failures where pthread.h does not exist:
sed: can't read
No such file or directory
This reverts commit d3c294ee0afe4d2eb46320945d41064ebfb5cbff.
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Replace the hardcoded path with /not/exist as used for other
options[--with-sysroot] to ensure pthread.h does not contain
hardocded references to TMPDIR:
ERROR: gcc-cross-canadian-x86-64-13.3.0-r0 do_package_qa: QA Issue:
File /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/
usr/lib/x86_64-poky-linux/gcc/x86_64-poky-linux/13.3.0/include-fixed/
pthread.h in package gcc-cross-canadian-x86-64 contains reference to
TMPDIR [buildpaths]
(From OE-Core rev: d3c294ee0afe4d2eb46320945d41064ebfb5cbff)
Signed-off-by: Sana Kazi <sanakazi720@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Apply fixes from gcc-cross (84a78f46d594 and 0ead8cbdfb96) to gcc-cross-canadian.
This will improve (but not fix) reproducibility of gcc-cross-canadian.
Also move this code to functions to avoid code duplication.
[RP: Tweak patch to make the function parameters clear and fix quoting issues
ensuring the code exactly matches the original replacements with an additional
parameter.]
(From OE-Core rev: 350ff7d53f7506de2bc01f0efc569b8294b9afea)
(From OE-Core rev: b1aa13b9f656666458189d4dae0c25564abe2f25)
Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com>
Signed-off-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit f1ad5be433)
Signed-off-by: Sana Kazi <sanakazi720@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Fixes https://bugzilla.yoctoproject.org/show_bug.cgi?id=15740
python3-setuptools-scm was ignoring GIT_CEILING_DIRECTORIES which is set by poky,
and it was thus finding a wrong value of "toplevel" in ./src/setuptools_scm/_file_finders/git.py
The code is supposed to generate the list of files contained in python3-setuptools-scm, but it was
instead running "git archive" on whatever git repository was above the build directory, because the
tarball containing the sources of python3-setuptools-scm does not contain a .git directory.
This is barely noticeable when building as a subdirectory of poky which is only 48MB, but this was
causing serious slowdowns of python3-setuptools-scm:do_compile when building
inside a big git repository with files tracked using git-lfs (50 minutes in my use-case).
Reported upstream as https://github.com/pypa/setuptools-scm/issues/1103
(From OE-Core rev: 4ebe72477484cf68165b6f736ce10373e97d0e6d)
(From OE-Core rev: 369eebad4f38c3641be73dbc0490c87636e0912d)
Signed-off-by: Etienne Cordonnier <ecordonnier@snap.com>
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
* backporting, because it's also needed also for qemu-native builds
on hosts with glibc >= 2.41
(From OE-Core rev: d34b38ecc2571fae0d58a34db1358dff2505148d)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Martin Jansa <martin.jansa@gmail.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
YOCTO [#15061]
The rust sdk installs both 'rust.sh' and 'cargo.sh' for lib32 and lib64 in the same location.
This causes below error while installing the lib32 & lib64 binaries:
Error: Transaction test error:
file /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/environment-setup.d/cargo.sh
conflicts between attempted installs of rust-cross-canadian-arm-1.67.1-r0.x86_64_nativesdk and
rust-cross-canadian-aarch64-1.67.1-r0.x86_64_nativesdk
file /usr/local/oe-sdk-hardcoded-buildpath/sysroots/x86_64-pokysdk-linux/environment-setup.d/rust.sh
conflicts between attempted installs of rust-cross-canadian-arm-1.67.1-r0.x86_64_nativesdk and
rust-cross-canadian-aarch64-1.67.1-r0.x86_64_nativesdk
ERROR: Task (virtual:multilib:lib32:/media/build/poky/meta/recipes-sato/images/core-image-sato.bb:do_populate_sdk)
failed with exit code '1'
The change includes:
- Prepending '${RUST_TARGET_SYS}' to 'rust.sh' to differentiate between target systems.
- Moving the non-target-specific environment variables to 'nativesdk-cargo' and 'nativesdk-rust',
instead of being managed by the cross-canadian recipe.
Backport from oe-core master: https://git.openembedded.org/openembedded-core/commit/?id=40eb4bfe2f100ba5301046ca25110fcc55a640bb
(From OE-Core rev: 889cda30baccd43e5c82b38752b462aef4ce626c)
Signed-off-by: Harish Sadineni <Harish.Sadineni@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This was prompted by working on librsvg update: the new meson-driven
version wants to query values from .pc files residing in its own
build directory, and modifies PKG_CONFIG_PATH accordingly.
When using the pkg-config-native wrapper such modifications
have no effect, and we have to pass them in manually
from the recipe via EXTRA_NATIVE_PKGCONFIG_PATH variable.
This variable is already defined (with an empty value) and
appended to PKG_CONFIG_PATH export in the native class, so this
simply extends its use to the wrapper.
(Appending to PKG_CONFIG_PATH in the wrapper, instead of resetting it,
is not an option as that can lead to contamination with the cross values).
(From OE-Core rev: 2bc050146d47b14d890a1b0db2b55f9057a08b65)
(From OE-Core rev: 104737073bd553b9cf93db7ed9575fd50ba6c973)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Chris Laplante <chris.laplante@agilent.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
During the execution of the command: i686-w64-mingw32-dlltool
--input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe
An error occurred:
i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s
Due to the path length exceeding the Linux system's file name length
limit (NAME_MAX=255), the temporary file name generated by the
i686-w64-mingw32-dlltool command becomes too long to open. To address
this, a new temporary file name prefix is generated using tmp_prefix =
prefix_encode ("d", getpid()), ensuring that the file name does not
exceed the system's length limit.
Allow for "snnnnn.o" suffix when testing against NAME_MAX, and tidy
TMP_STUB handling by overwriting a prior nnnnn.o string rather than
copying the entire name.
(From OE-Core rev: 617df4ee1d6523ded43f156af8206dfca2c0c8ee)
Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Below commits on binutils-2.42 stable branch are updated.
758a2290dbd PR32387 ppc64 TLS optimization bug with -fno-plt code
ed489bf1574 s390: Add arch15 Concurrent-Functions Facility insns
64e8e16a906 s390: Add arch15 instruction names
Tested on qemux86_64.
There were no additional PASS or FAIL after the update
(From OE-Core rev: 6ce232df15834cae44f3eda0f786132086afb76e)
Signed-off-by: Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This does not seem to be used in regular builds, but is beneficial
in rust selftest, where it allows dropping a custom patch
that is unsuitable for upstream (and was rejected by them).
Also remove an obsolete comment that seems related to the code
but describes something that was resolved long time ago.
I have confirmed that the rust selftest continues to pass with just
this one commit on top of master (as the following changes do break
the selftest).
(From OE-Core rev: 9b23f995fbc1886c36f02b0c6e1ccaf2ee0f6daa)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit bf5732e2b235ce06fa1f24fe8f0dbcbc068500e3)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Otherwise, use rust-native and cargo-native binaries as that allows
our native tweaks in them to be used for target/nativesdk rust -
same as for everything else written in rust.
In particular, this allows building target rust with
cargo-native that includes important reproducibility tweaks.
Unfortunately, this also breaks rust selftest, and that
is partially addressed by the following commit.
[YOCTO #15185]
(From OE-Core rev: d592bc02b0846411796c1d481c09833559d1d29f)
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 8f2230cb51fe22ef4711a56fecfab4858c04e35b)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. This vulnerability arises from a race condition during
rsync's handling of symbolic links. Rsync's default behavior when encountering
symbolic links is to skip them. If an attacker replaced a regular file with a
symbolic link at the right time, it was possible to bypass the default behavior
and traverse symbolic links. Depending on the privileges of the rsync process,
an attacker could leak sensitive information, potentially leading to privilege escalation.
(From OE-Core rev: e85beb88add5e94567d7221e00cabfb3d5010be7)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. When using the `--safe-links` option, rsync fails to
properly verify if a symbolic link destination contains another symbolic link within it.
This results in a path traversal vulnerability, which may lead to arbitrary file write
outside the desired directory.
(From OE-Core rev: dad4a83c011310872cce07fc4141e66a98439cb1)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A path traversal vulnerability exists in rsync. It stems from behavior enabled
by the `--inc-recursive` option, a default-enabled option for many client options
and can be enabled by the server even if not explicitly enabled by the client.
When using the `--inc-recursive` option, a lack of proper symlink verification
coupled with deduplication checks occurring on a per-file-list basis could allow
a server to write files outside of the client's intended destination directory.
A malicious server could write malicious files to arbitrary locations named after
valid directories/paths on the client.
(From OE-Core rev: c34cbef572e18c60bb7600fda370d6c46688c7b3)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in rsync. It could allow a server to enumerate the contents of an
arbitrary file from the client's machine. This issue occurs when files are being
copied from a client to a server. During this process, the rsync server will send
checksums of local data to the client to compare with in order to determine what
data needs to be sent to the server. By sending specially constructed checksum values
for arbitrary files, an attacker may be able to reconstruct the data of those files
byte-by-byte based on the responses from the client.
(From OE-Core rev: 19f4e7bd965c63f19cc756e6e2bf8f58d9e1dc8d)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A flaw was found in the rsync daemon which could be triggered when rsync compares
file checksums. This flaw allows an attacker to manipulate the checksum length
(s2length) to cause a comparison between a checksum and uninitialized memory and
leak one byte of uninitialized stack data at a time.
(From OE-Core rev: fb8439e856d5ea10d12180020a14442c3b101e56)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
A heap-based buffer overflow flaw was found in the rsync daemon. This issue is due
to improper handling of attacker-controlled checksum lengths (s2length) in the code.
When MAX_DIGEST_LEN exceeds the fixed SUM_LENGTH (16 bytes), an attacker can write
out of bounds in the sum2 buffer.
(From OE-Core rev: ad0e13912b17ca19ffbd7ea6a366f7c968517fb2)
Signed-off-by: Archana Polampalli <archana.polampalli@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The '-fdebug-prefix-map' options are used to map source files locations,
otherwise, DW_AT_comp_dir will contain buildpath.
The '-gno-record-gcc-switches' option is used to fix the buildpath introduced
by '-fintrinsic-modules-path' option, which is automatically added by fortran.
Here's some output from 'readelf --debug-dump libgfortran.so.5.0.0' when this
option is not added:
"""
<0><1a37d3>: Abbrev Number: 4 (DW_TAG_compile_unit)
<1a37d4> DW_AT_producer : (indirect string, offset: 0xd653): GNU Fortran2008 14.2.0 -m64
-march=core2 -mtune=core2 -msse3
-mfpmath=sse -mshstk -g -O2 -O2 -fstack-protector-strong -fimplicit-none
-fno-repack-arrays -fno-underscoring -fcf-protection=full
-fallow-leading-underscore -fbuilding-libgfortran -fPIC
-fintrinsic-modules-path /ala-lpggp72/qichen/Yocto/builds/build-poky/tmp/work/
core2-64-poky-linux/libgfortran/14.2.0/recipe-sysroot-native/usr/bin/x86_64-poky-linux
/../../lib/x86_64-poky-linux/gcc/x86_64-poky-linux/14.2.0/finclude
-fpre-include=../../../../recipe-sysroot/usr/include/finclude/math-vector-fortran.h
"""
See https://gcc.gnu.org/pipermail/fortran/2024-October/061204.html for more
detailed information.
(From OE-Core rev: 660e00469f9c99fe733cc8b37f67438a96ff2e97)
Signed-off-by: Chen Qi <Qi.Chen@windriver.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Using the package architecture to select the right qemu options to pass
to qemu-user is incorrect, and fails for recipes that set PACKAGE_ARCH
to MACHINE_ARCH (as the qemuppc workarounds suggest) because there are
not typically any options set for the machine name.
Solve this by using TUNE_PKGARCH instead: for the majority of recipes
this is the same value, but for machine-specific recipes it remains the
same instead of changing to the machine name.
This means we can remove the qemuppc workarounds, as they're obsolete.
Also update the gcc-testsuite recipe which uses the same pattern to use
TUNE_PKGARCH, and generalise the else codepath to avoid needing to
update the list of architectures.
[ YOCTO #15647 ]
(From OE-Core rev: 972ca555ff3aa41d32980477850c92915b6395ed)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 414b754a6cbb9cc354b1180efd5c3329568a2537)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Changelog:
https://requests.readthedocs.io/en/latest/community/updates/#release-history
2.32.3 (2024-05-29)
* Bugfixes - Fixed bug breaking the ability to specify custom SSLContexts
in sub-classes of HTTPAdapter. (#6716)
* Fixed issue where Requests started failing to run on Python versions
compiled without the ssl module. (#6724)
2.32.2 (2024-05-21)
* Deprecations - To provide a more stable migration for custom HTTPAdapters
impacted by the CVE changes in 2.32.0, we’ve renamed _get_connection to a
new public API, get_connection_with_tls_context. Existing custom
HTTPAdapters will need to migrate their code to use this new API.
get_connection is considered deprecated in all versions of
Requests>=2.32.0.
* A minimal (2-line) example has been provided in the linked PR to ease
migration, but we strongly urge users to evaluate if their custom adapter
is subject to the same issue described in CVE-2024-35195. (#6710)
2.32.1 (2024-05-20)
* Bugfixes - Add missing test certs to the sdist distributed on PyPI.
https://github.com/psf/requests/compare/v2.32.0...v2.32.3
Also transition to using python_setuptools_build_meta.
(From OE-Core rev: e1787271b07c605df2843d82d65e1c3d2e2114e6)
Signed-off-by: Soumya Sambu <soumya.sambu@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
importlib.metadata is part of -core, but that will import zipfile which
is part of -compression.
Obviously this shows that our packaging of the Python modules is not
optimal. I plan to follow up with a redesign of the splitting which
focuses on simply pulling out the larger or esoteric modules and
having a more featureful core.
(From OE-Core rev: 05166eafb99cf8c7adb6879277069ab384a2f8df)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
The fix brought by this patch is already part of python 3.12.3
therefore drop it.
(From OE-Core rev: 555623d2378138fdcfae95c04e06ba384cebab5b)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
This commit updates the warning to use a check for "trivially constructible" instead of
"trivially copyable." The original check was incorrect, as "trivially copyable" only applies
to types that can be copied trivially, whereas "trivially constructible" is the correct check
for types that can be trivially default-constructed.
This change ensures the warning is more accurate and aligns with the proper type traits.
LLVM accepted a similar fix:
https://github.com/llvm/llvm-project/issues/47355
PR c++/116731 [https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116731]
(From OE-Core rev: 614a8e3a06003dfcbf1f32dc2d6f4d18f74b71a4)
Signed-off-by: Marek Polacek <polacek@redhat.com>
Signed-off-by: Sunil Dora <sunilkumar.dora@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Insufficient validation of filenames against control characters in
Apache Subversion repositories served via mod_dav_svn allows
authenticated users with commit access to commit a corrupted revision,
leading to disruption for users of the repository. All versions of
Subversion up to and including Subversion 1.14.4 are affected if serving
repositories via mod_dav_svn. Users are recommended to upgrade to
version 1.14.5, which fixes this issue. Repositories served via other
access methods are not affected.
References:
https://nvd.nist.gov/vuln/detail/CVE-2024-46901
Upstream patches:
https://subversion.apache.org/security/CVE-2024-46901-advisory.txt
(From OE-Core rev: 16c212bd9a9e9c35256ff308da72a518c76ce11d)
Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com>
Signed-off-by: Steve Sakoman <steve@sakoman.com>
