mirror of
https://github.com/libretro/RetroArch.git
synced 2024-05-20 13:27:22 -04:00
13cf3cdef2
This is a potential security issue. The problem is that config.h and config.mk are populated with all variables prefixed with 'HAVE_' from the user's environment. Example: $ HAVE_FOO=yes ./configure $ grep FOO config.mk HAVE_FOO = 1 $ grep FOO config.h #define HAVE_FOO 1 After this commit these files will only use variables set by qb configure process and not from the user's environment. This issue could result in hard to diagnose undefined behavior or maybe worse? The user should experience no change in behavior, but developers should be more careful about setting 'HAVE_' variables manually. Unless the FOO variable is used by check_enabled ($2 only), check_platform, check_lib, check_pkgconf, check_header, check_macro or check_switch functions it should be set at least once by the new add_opt function. The first argument should be 'FOO' which matches the HAVE_FOO variable and the second argument should contain 'auto', 'no' or 'yes'. Example: add_opt FOO yes When in doubt its safe to use add_opt. This will also fix a few potential issues where configure arguments used by the user are ignored. When the second argument is not set the FOO variable will only be used to populate config.h and config.mk with its current value. This should only be done in qb/qb.libs.sh in functions that set 'HAVE_' variables.
14 lines
378 B
Bash
14 lines
378 B
Bash
# Creates config.mk and config.h.
|
|
vars=''
|
|
add_define MAKEFILE GLOBAL_CONFIG_DIR "$GLOBAL_CONFIG_DIR"
|
|
eval "set -- $CONFIG_OPTS"
|
|
while [ $# -gt 0 ]; do
|
|
tmpvar="${1%=*}"
|
|
shift 1
|
|
var="${tmpvar#HAVE_}"
|
|
vars="${vars} $var"
|
|
done
|
|
VARS="$(printf %s "$vars" | tr ' ' '\n' | $SORT)"
|
|
create_config_make config.mk $(printf %s "$VARS")
|
|
create_config_header config.h $(printf %s "$VARS")
|