A remote code execution vulnerability in GNOME

I'm no C programmer, but would a better solution in this case be to use posix_spawn to start a separate process which solely reads the file being indexed and returned text. With the assumption that a separate spawned executable could be locked down stricter with seccomp than a forked thread in the same process namespace?

Still, the problem with the argument that seccomp only failed in this case because tracker-miner used it wrong, is that it is an argument of purity, like no true Scotsman...

On the other hand: OpenSSH also uses seccomp, and is implemented in C, and handles untrusted user input in a privileged environment. So, apparently for some true Scotsmen, like the OpenSSH developers, it seems to be possible to not fail to implement secure software in the C programming language. Though, that might be the exception which proves the rule?

The author of both the current fix and the previous implementation of seccomp in tracker-miners confirms (AFAIU) that the seccomp sandbox in tracker-miner was and is a compromise. Many of the libraries tracker-miner use to extract text from files were not designed with confinement and seccomp in mind. So it seems that tracker-miner had to lower the guards to get any useful output at all. Still, when that compromise was on the table, a better option would have been to abandon that aproach and find another more appropriate way forward. One that didn't compromise security for sake of features.

BTW, tracker-miner still use Gstreamer to parse files, despite Gstreamer being a known source of security issues. Reported by LWN already in 2016.
https://lwn.net/Articles/708196/