Slashdot Mirror
TSYNC Not a Hard Requirement For Google Chrome After All
An anonymous reader writes A few days ago it appeared that Google began requiring new versions of the Linux kernel for the Chrome/Chromium web browser. To some people, such requirement smelled funny, and it turns out that those people had the right hunch. Google does not intend for there to be a hard requirement on the latest versions of the Linux kernel that expose SECCOMP_FILTER_FLAG_TSYNC, but instead many users are hitting an issue around it. A Chromium developer commented on the related bug: "Updating the title so that people who have been mislead into thinking non-TSYNC kernels were deprecated immediately understand that there is simply 'some unknown bug' hitting some users." Of course, a user having the TSYNC feature in his kernel will still get a security benefit.
People, the problem is the people
The earlier story was trying to make Debian look arbitrary and anti-Google for not making changes to a frozen release.
It's important to retract that and clarify that this is all about a bug on Google's part.
Googling for "TSYNC" or "Linux TSYNC" or "what is TSYNC" brings up shittons of news about Chrome, but nothing about tsync.
Support my political activism on Patreon.
The linux seccomp feature provides application sandboxing. Chrome uses it to sandbox tabs from each other and native plugins from the rest of the system.
Seccomp is accessed through the seccomp (2) system call. The SECCOMP_FILTER_FLAG_TSYNC flag is an option to seccomp (2) that transparently synchronises the effect of the call across all sandboxed threads.
foo mane padme hum
Chrome/chromium stopped working properly on at least some systems running kernels without the tsync feature (which is a very new feature). At the time people assumed that google was intentionally requiring the new feature. Chromium is one of those programs where the only reasonable way to support it is to keep upgrading to new upstream versions. Even Debian breaks from their normal policies when it comes to major web browsers.
It's one thing to break with your normal policies of "security and major bugfixes only" for updates to a web browser. It's altogether more contraversial if doing so requires making changes to core system components to support said web browser hence why this situation blew up a few days ago.
Google has now clarified that chromium is supposed to work without the kernel feature in question.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
...it won't require NSYNC.
They usually say "that bug was fixed already in our latest version. Go bug your distro to update their packages." And thus the buck is ever passed.
That is not passing the buck, that is upstream developers correctly leaving packaging up to the distribution maintainers. If I release a piece of open-source software, and it gets packaged (by people other than myself) for multiple Linux distributions, do I - as upstream maintainer - suddenly become responsible for the care and maintenance of those packages, in distributions I may not even be aware were packaging my software, let alone have any sort of commit access to? Would you expect me to go through the rigmarole of becoming a Debian developer, for example, just so that I can ensure the Debian package of my software (which I didn't even create, I just release tarballs of code) is always bleeding edge?
If a distribution moves too slowly for your tastes, that is a problem with the distribution, and upstream are not beholden to you to fix it.