The #WebP #security vulnerability CVE-2023-4863 demonstrates a huge advantage of the "distro" approach of shipping software, like #Debian pushes so hard to deliver. We see a mad scramble for many software vendors to ship with the patched version of #libwebp. In the distro model, the patch is shipped in the single lib package, then all of the software automatically uses the safe version. This leads to shorter times to get fixes to users with much less work overall.
@frehi exactly, this is what Debian works hard to avoid, but #Google has refused to budge at all with #Chromium in this regard. They make it impossible to build in the distro style, with shared libraries, etc.. It must be all statically linked with everything from its own source package. Looks like Firefox also has started to go this route, though historically, they've had a more flexible build that was less hostile to distros.
@eighthave Apparently there there is a --with-system-webp build option, looking at https://github.com/void-linux/void-packages/blob/master/srcpkgs/firefox/template
But I guess there is a good reason why Debian does not use it.
@frehi I've worked on Chromium quite a bit, in terms of patching and building, so I'm speaking from that experience. I don't know much about Firefox in Debian.
@frehi I've heard some more details: Debian's Chromium maintainer actually got it to use the system libwebp https://salsa.debian.org/chromium-team/chromium/-/blob/master/debian/control
And Mozilla maintains the Firefox packages in Debian, they decided to not use the system libwebp, though their build system supports it.
@frehi @eighthave the reason is mostly that Debian backports the security fixes, not the entire library, and Firefox is notirious in requiring the absolute latest versions, so when Firefox LTS get backported they cannot work with the libs in the stable release within reasonable manpower. This is something to address on the Firefox level.
Using the vendored libs is a last resort "we have to get the Firefox update out there now" thing. Sometimes, the newer libraries are backported under different names which then just the backported newer browsers use, but not the regular packages in the stable release. But again this is not always possible, or possible to do in time.
And the underlying reason for rejecting the distro model is that "You can't have the shiniest new thing, and not be part of the Cool Kids Club."
@niclas @eighthave maybe just use a rolling release distro then?
I was more referring to rapid turnover of client-side web frameworks over the last 10 years. By the time distros discover that a lot of people are using X, X is on the way out by the Cool Kids and they are moving on...
A bit of an exaggeration, but there is some truth to it. I was the same 20 years ago.
@jr @niclas A rolling release distro wouldn't change this issue. If each package includes its own copy of libwebp, each one of those still needs to be updated. With this #WebP vuln, it was first reported as only affecting some iOS framework, then only Chrome. So lots of developers are still not aware that they have to ship an update with the latest libwebp version. With the distro model, just the library maintainer needs to be aware of the update, then all the apps automatically get the update
@eighthave unfortunately in 15 years it still hasn't changed much in terms of mindshare
https://flameeyes.blog/2009/01/02/bundling-libraries-for-despair-and-insecurity/
@eighthave @flameeyes it has gotten worse, what with issue9 (and crab IIRC) basically demanding static linking… which is mildly better than vendoring, what they also tend to do.
@eighthave debian 4 life
@eighthave I agree completely. Unfortunately it seems like the Firefox package uses its own libwebp copy, because there was a separate Firefox security update
https://www.debian.org/security/2023/dsa-5496
and the package does not depend on libwepb7.