https://security-tracker.debian.org/tracker/CVE-2019-6293https://github.com/NixOS/nixpkgs/issues/55386#issuecomment-683792976
"But this bug does not cause stack overflows in the generated code.
The function and file referred to in the bug (mark_beginning_as_normal
in nfa.c) are part of the flex code generator, not part of the
generated code. If flex crashes before generating any code, that
can hardly be a vulnerability. If flex does not crash, the generated
code is fine (or perhaps subject to other unreported bugs, who knows,
but the NFA has been generated correctly)."
Upstream has chosen to not provide a fix
https://github.com/westes/flex/issues/414
Signed-off-by: Matthew Weber <matthew.weber@rockwellcollins.com>
[yann.morin.1998@free.fr: use actual upstream URL]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
FOO_CPE_ID_VALID really ought to be an internal implementaion detail.
Packages that really want to trigger their CPE defintitions really
should set one of the actual variables to a meaningful value.
There are two CPE-related variables that we could chose to set to
replace FOO_CPE_ID_VALID: FOO_CPE_ID_VENDOR and FOO_CPE_ID_PRODUCT.
Between those two, _VENDOR more often diverges from the default than
_PRODUCT does, so that's what we use.
---8<------8<------8<------8<------8<---
#!/bin/bash
# Replace FOO_CPE_ID_VALID = YES with FOO_CPE_ID_VENDOR = foo_project
for i in $(git grep -l -E '[^)]_CPE_ID_VALID = YES' package support); do
pkg="$(basename "${i%/*}")"
sed -r -i -e "s/_CPE_ID_VALID = YES/_CPE_ID_VENDOR = ${pkg}_project/" "${i}"
done
---8<------8<------8<------8<------8<---
Reported-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Matthew Weber <matthew.weber@rockwellcollins.com>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: update cpe-test comment to reflect pkg3 change]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Currently, the target and host flex packages do not behave the same in
terms of patching: the target variant has a patch hook that disables
building the programs (because they are not needed, and do not build
on no-MMU platforms). However, this hook is obviously not executed for
host-flex, because we really want the host flex binary to be built.
In preparation for the introduction of out-of-tree package build, it
is important that we don't do different things in the patch hooks for
the target and host variant of a given package, because the source
tree will be shared between the target and host builds.
To solve this, we introduce a --disable-program configure option,
through a patch to the flex configure.ac and Makefile.am. This patch
makes the current 0001-flex-disable-documentation.patch no longer
needed.
Furthermore, building the documentation is a PITA: flex.1 depends on
configure.ac and a few other files generated during the build. Touching
flex.1 does not work, because automake will forcibly remove the files
when its prerequisites are too old, so pre-requisites of flex.1 will
always be more recent than flex.1. So, we add a patch that adds a
--disable-doc configure option.
Fixes:
http://autobuild.buildroot.org/results/f70/f70b39632535bb9692d0a032166b2f4104532967/http://autobuild.buildroot.org/results/525/52567afdfe7992b3518de0e01227ba14aa300f21/
[...]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[yann.morin.1998@free.fr:
- rebase on-top of master,
- add patch to not build the documentation, because simply touching
flex.1 is no longer enough.
- keep install in target/, for shared builds
]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Adrian Perez de Castro <aperez@igalia.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When the host uses glibc 2.26 or newer, Flex will try to use the
newly-introduced reallocarray() function, but as it would not define
_GNU_SOURCE a segmentation fault would occur later on due to the
compiler assumming that the function is implicitly defined.
This issue manifests itself due to a crash of "stage1flex" during the
Flex bootstrap:
./stage1flex -o stage1scan.c ./scan.l
make[2]: *** [Makefile:1725: stage1scan.c] Segmentation fault (core dumped)
This imports the patch from the upstream Git repository, and adds flags
in the .mk file to rebuild the Autotools scripts and support files. Due
to the latter, the patch to disable the documentation is changed so it
modifies the .am file instead.
Signed-off-by: Adrian Perez de Castro <aperez@igalia.com>
[Arnout:
- Add Adrian's Sob and upstream ref to new patch;
- Keep patch 1 as patch 1;
- Keep Vicente as author of path 1;
- Add reason for autoreconf in a comment.]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This doesn't compile with glibc 2.26 where reallocarray() as been introduced.
It's a nasty issue, when reallocarray() is available for the target, flex will
build a small tool called stage1flex for the host (using _FOR_BUILD) but with
the config.h generated for the target.
When the host doesn't have a glibc >= 2.26, reallocarray() is never defined
while building stage1flex:
misc.c:147:8: warning : implicit declaration of function « reallocarray »
[-Wimplicit-function-declaration]
mem = reallocarray(NULL, (size_t) size, element_size);
^~~~~~~~~~~~
misc.c:147:6: warning : assignment makes pointer from integer without a cast
[-Wint-conversion]
mem = reallocarray(NULL, (size_t) size, element_size);
^
Disable reallocarray for now, reallocarray() support may be
enabled in a followup patch.
Fixes:
stage1flex-misc.o: In function `allocate_array':
misc.c:(.text+0x38f): undefined reference to `reallocarray'
stage1flex-misc.o: In function `reallocate_array':
misc.c:(.text+0xc8a): undefined reference to `reallocarray'
collect2: error: ld returned 1 exit status
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This commit switches to use the new gettext logic, which involves:
- using TARGET_NLS_DEPENDENCIES instead of hand-encoded dependencies
on gettext/host-gettext
- dropping BR2_PACKAGE_GETTEXT selection
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The comment that explains why we were defining HOST_FLEX_DEPENDENCIES
instead of inheriting from FLEX_DEPENDENCIES no longer makes sense,
since we remove such automatic inheritance of host dependencies from
target dependencies a while ago.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We do want to build the flex binary when building host-flex since it's
needed as a build dependency for other packages.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
- 0001 patch removed. It doesn't apply on this version and is also not
necessary since the AR binary is now handled correctly with AR = @AR@.
- 0002 patch removed. It's already included in this release:
a5cbe929ac
- The flex project has moved to GitHub, so modify the URLs in both
flex.mk and Config.in files.
- The sed command over Makefile.in to prevent the flex binary to be
built fails, so remove it. That logic has been moved to
src/Makefile.in, and whenever we disable the flex binary to be built
then the compilation fails when building the documentation because
some bits require "../src/flex", which is the flex binary.
We prevent building the flex binary and the documentation using a new
patch.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It's been deprecated for a year now so remove the option.
Also rename patch to new naming convention.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since SourceForge sometimes serves us faulty tarballs, we can tons of
autobuild failures:
http://autobuild.buildroot.org/results/9fb/9fba5bf086a4e7a29e5f7156ec43847db7aacfc4/http://autobuild.buildroot.org/results/6c8/6c837b244c45ac3b3a887734a371cd6d226cf216/
...
Fix that by adding hash files for all SourceForge-hosted packages (thos
etht did not already have it).
We normally prefer to use hashes published by upstream, but hunting them
all one by one is a tedious task, so those hashes were all locally
computed with a script that searched for SF-hosted packages, downloades
the associated tarball, computed the hash, and stored it in the
corresponding .hash file.
Also, SF publishes sha1 hashes, while I used the stronger sha256, since
sha1 is now considered to be relatively weak.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Richard Braun <rbraun@sceen.net>
Cc: Nathaniel Roach <nroach44@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When flex is built for the target without installing the
flex binary, a flex++ symlink installed by flex's Makefile
points to the missing flex executable. This mod adds
a post target install hook to remove the broken symlink.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The buildroot manual contains a list of deprecated items, with their config
title text, and the location in the config menu. If the config text does not
mention a package name, this can be confusing.
For example, the symbol BR2_PACKAGE_FLEX_BINARY has as text:
'Install tool in the target', which outside of the flex context makes no
sense at all.
To make sure the deprecated packages list in the manual is understandable,
rename the (deprecated) flex 'target binary' config option.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order to keep better track of when a feature got deprecated, and hence
when it can be removed, a new set of symbols BR2_DEPRECATED_SINCE_xxxx_xx is
introduced. These symbols are automatically selected when BR2_DEPRECATED is
selected, and thus are transparent to the user.
A deprecated feature will no longer depend on BR2_DEPRECATED directly, but
rather on the appropriate BR2_DEPRECATED_SINCE_xxxx_xx. If that symbol does
not yet exist, it has to be created in Config.in.
When removing a deprecated feature, one should also check whether this was
the last feature using the BR2_DEPRECATED_SINCE_xxxx_xx symbol, in which
case the latter can be removed from Config.in.
A followup patch will make sure the overview is added to the list of
deprecated features in the manual, so that a buildroot core developer can
easily determine which features to remove in a given development cycle.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since some time, we have removed the support to build a toolchain for
the target, and therefore the support for several development tools on
the target.
This commit deprecates a few additional development tools: m4, bison,
flex and gob2. For flex, we retain the ability to build libfl, we only
deprecated the ability to build the flex binary itself.
The original motivation for this patch is that m4 is causing build
issues in some configurations, but there isn't really much incentive
to fix this package for the target, since it is not really useful for
embedded Linux systems.
Bison, Flex and Gob2 are deprecated because they are reverse
dependencies of m4.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When a package A depends on config option B and toolchain option C, then
the comment that is given when C is not fulfilled should also depend on B.
For example:
config BR2_PACKAGE_A
depends on BR2_B
depends on BR2_LARGEFILE
depends on BR2_WCHAR
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
This comment should actually be:
comment "A needs a toolchain w/ largefile, wchar"
depends on BR2_B
depends on !BR2_LARGEFILE || !BR2_WCHAR
or if possible (typically when B is a package config option declared in that
same Config.in file):
if BR2_B
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
[other config options depending on B]
endif
Otherwise, the comment would be visible even though the other dependencies
are not met.
This patch adds such missing dependencies, and changes existing such
dependencies from
depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC
to
depends on BR2_BASE_DEP
depends on !BR2_TOOLCHAIN_USES_GLIBC
so that (positive) base dependencies are separate from the (negative)
toolchain dependencies. This strategy makes it easier to write such comments
(because one can simply copy the base dependency from the actual package
config option), but also avoids complex and long boolean expressions.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since fe6a9e5e9d (flex: needs M4 at runtime), the autobuilders have
been producing a number of flex related build failures. They have been
hard to track down, because even on the same machine, with the same
Git commit ID and the same configuration, the failure could not be
reproduced.
However, a close inspection of flex's config.log file allowed to find
out what the problem was. In its configure script, flex uses the
host-flex to generate a minimal example, and find out the name of the
output file of flex.
When the M4 environment is passed when building the target flex, it
also affects the *execution* of the host-flex, which tries to use
/usr/bin/m4 (which doesn't exist in the autobuilder machines) instead
of the one built in $(HOST_DIR)/usr/bin/m4. So generating the minimal
example fails. And this is where what I could reproduce and what the
autobuilders script produce differ: in my case, even though host-flex
fails to run, it creates an empty lex.yy.c, which is enough to make
the configure script happy. In the context of the autobuild scripts,
this file is apparently not created at all, for an unknown reason, and
this leads to the configure script to abort.
The fix is to set ac_cv_path_M4. This will affect the default m4 used
by the target flex, but it will not affect the m4 used by the
host-flex. It allows the test made during the configure script to work
properly, and therefore should fix the issue seen in the autobuilders.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For proper runtime execution, flex requires m4 to be
installed. Passing a M4 variable at configure time is needed,
otherwise flex on the target will try to use a 'm4' binary with a
build machine path.
Fixes bug #4988.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The flex binary uses fork() so it breaks on !MMU builds.
Since we usually don't require flex in the target and the common
scenario is that we just want libfl in staging reverse the options so
that BR2_PACKAGE_FLEX just builds and install libfl.a and change the
LIBFL option to BR2_PACKAGE_FLEX_BINARY to install the binary in the
target.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
From now on, packages only need to select the BR2_PACKAGE_GETTEXT
option and depend on the 'gettext' package to get the necessary i18n
libraries installed on the target.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: remove BR2_PACKAGE_LIBINTL]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
CC: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thanks to the pkgparentdir and pkgname functions, we can rewrite the
AUTOTARGETS macro in a way that avoids the need for each package to
repeat its name and the directory in which it is present.
[Peter: pkgdir->pkgparentdir]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Flex doesn't NEED gettext/libintl, but it's configure script checks for it,
so make sure those a built before flex, otherwise flex will populate
tgt-config.cache with invalid values, breaking the build of other packages
needing it (like libglib2).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Version 9 is no more available on Debian FTP.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Flex contains a libfl.a directory, which programs for the target might
link against. Therefore, we need to install flex to the staging
directory. An example of such a program is gob2, which needs the
yywrap() function, which is implemented by libfl.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Could not apply when missing top level Makefile, which is also
regenerated by the configure script.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We have been passing -q to ./configure when using 'make -s' for
packages using Makefile.autotools.in for some time. Do the same
for packages using autotools, but not using the
Makefile.autotools.in infrastructure, taking care to not do it
for packages with hand written configure scripts.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A C library will have been built by the toolchain makefiles, so there is no
need for packages to explicitly depend on uclibc.
Signed-off-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
