Dz: Seccomp sandboxing not enabled for acme-client

In the acme-client-portable repository at GitHub, developer Kristaps Dz has a rather stinging indictment of trying to use seccomp sandboxing for the portable version of acme-client, which is a client program for getting Let's Encrypt certificates. He has disabled seccomp filtering in the default build for a number of reasons. "So I might use mmap, but the system call is mmap2? Great. This brings us to the second and larger problem. The C library. There are several popular ones on Linux: glibc, musl, uClibc, etc. Each of these is free to implement any standard function (like mmap, above) in any way. So while my code might say read, the C library might also invoke fstat. Great.In general, section 2 calls (system calls) map evenly between system call name and function name. (Except as noted above... and maybe elsewhere...) However, section 3 is all over the place. The strongest differences were between big functions like getaddrinfo(2).Then there's local modifications. And not just between special embedded systems. But Debian and Arch, both using glibc and both on x86_64, have different kernels installed with different features. Great.Less great for me and seccomp." (Thanks to Paul Wise.)