Re: seccomp woes (was: file(1) now with seccomp support enabled)
On Sat, 20 Jul 2019 at 00:21:10 +0200, Christoph Biedl wrote:
> The build system of the file package uses autoconf to check for
> presence of the seccomp library and will just disable that feature if
> support is missing. But just adding "libseccomp-dev" will break the
> build on e.g. alpha for an unsatisfyable build dependency - I don't
> wish to simply ignore that. So I have to make sure lack of seccomp in
> these architectures does not break the build.
... unless seccomp is sufficiently important to your dependent package
that you would prefer for your dependent package not to be available
on non-seccomp architectures until seccomp becomes available there.
For file(1) it certainly seems better to consider seccomp to be a
hardening/quality-of-implementation thing and fall back to not having it;
for flatpak I decided it was better to have flatpak remain unavailable
on non-seccomp architectures, because there are some sandbox escapes
that are only prevented by it using seccomp. Both approaches can be valid,
depending on the dependent package.
smcv
Reply to: