Files being installed by Portage are generally trusted but also the
syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the
syscalls used by file can change which leads to its seccomp filter killing
the process. This is an acceptable tradeoff when users are calling file(1),
but it makes less sense with trusted input within Portage, especially
where it may lead to confusing errors (swallowed within pipes, subshells,
etc).
Indeed, it might even be the case that file(1) is broken, but the user
needs to complete a world upgrade to get a newer file/portage/???, but
can't because of various ebuilds (like ones using this eclass) failing.
Disable seccomp for these calls to keep working.
Bug: https://bugs.gentoo.org/811462
Bug: https://bugs.gentoo.org/815877
Bug: https://bugs.gentoo.org/889046
Signed-off-by: Sam James <sam@gentoo.org>
Files being installed by Portage are generally trusted but also the
syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the
syscalls used by file can change which leads to its seccomp filter killing
the process. This is an acceptable tradeoff when users are calling file(1),
but it makes less sense with trusted input within Portage, especially
where it may lead to confusing errors (swallowed within pipes, subshells,
etc).
Indeed, it might even be the case that file(1) is broken, but the user
needs to complete a world upgrade to get a newer file/portage/???, but
can't because of various ebuilds (like ones using this eclass) failing.
Disable seccomp for these calls to keep working.
Bug: https://bugs.gentoo.org/811462
Bug: https://bugs.gentoo.org/815877
Bug: https://bugs.gentoo.org/889046
Signed-off-by: Sam James <sam@gentoo.org>
Files being installed by Portage are generally trusted but also the
syscalls allowed by file are quite broad anyway.
With e.g. new libc or sandbox version (or any number of things...), the
syscalls used by file can change which leads to its seccomp filter killing
the process. This is an acceptable tradeoff when users are calling file(1),
but it makes less sense with trusted input within Portage, especially
where it may lead to confusing errors (swallowed within pipes, subshells,
etc).
Indeed, it might even be the case that file(1) is broken, but the user
needs to complete a world upgrade to get a newer file/portage/???, but
can't because of various ebuilds (like ones using this eclass) failing.
Disable seccomp for these calls to keep working.
Bug: https://bugs.gentoo.org/811462
Bug: https://bugs.gentoo.org/815877
Bug: https://bugs.gentoo.org/889046
Signed-off-by: Sam James <sam@gentoo.org>
It's a policy requirement that ebuilds produce verbose logs, so ebuilds themselves
must not set CMAKE_VERBOSE. But users can.
Signed-off-by: Sam James <sam@gentoo.org>
Sam James
Ionen Wolkens
Sebastian Pipping
Maciej Barć
Sergei Trofimovich
Matt Turner
David Seifert
Andreas Sturmlechner
Georgy Yakovlev
Rick Farina
Arthur Zamarin