Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #6533

Re: Feasibility to patch libskia moving forward

Show all headers | View raw

Den 2026-10-08 kl. 16:16, skrev John Scott:
> You may already be aware but it deserves an explicit mention: WebKitGTK now requires the use of Skia for graphics. And if the words "WebKitGTK" and "Skia" together are giving anyone déjà vu, that's because of the recent debian-devel thread "WebKitGTK and architecture support in Debian".
>   ◦ As an aside, the reason that Skia isn't portable isn't due to a genuine constraint, but to my understanding, it's simply because the code was written to correspond to little-endian byte ordering when "type punning" or manipulating the in-memory representation of various data types. Such problems have been well-known since antiquity and is a sign of poorly-written code, which wouldn't be a big deal if folks at Google were to care. See UNIX Network Programming (Third Edition, by W. Richard Stevens et al) page 80 for example:
>   🙶A common network programming error in the 1980s was to develop code on Sun workstations (big-endian Motorola 68000s) and forget to call any of these four functions [htons(), htonl(), ntohs(), ntohl()]. The code worked fine on these workstations, but would not work when ported to little-endian machines (such as VAXes).🙷

I saw the discussion - and I saw the issue when packaging Skia ~6 months 
ago. The error message says "The Skia team is not endian-savvy enough to 
support big-endian CPUs...", which to me reads in line with your 
understanding, perhaps in combination with a lack of regular testing on 
big-endian machines.

> 
> Anyway, here are a couple important details about WebKitGTK and what it means for us:
>   ‣ WebKitGTK is supported in Debian stable releases by providing new stable releases as needed, but it's a big undertaking and a miracle that the maintainers and security team were able to make this work at all.
>   ‣ Currently WebKitGTK uses an embedded code copy of Skia as provided in the WebKitGTK releases, so it doesn't use your proper libskia package at all. In fact WebKitGTK doesn't even have a build option to try using a system copy, but I've filed a request at https://webkit.org/b/320369 to make the desire known.

This is sadly in line with the recommendations from upstream. The tone 
is essentially: link it statically with your program. At least they do 
have build options for shared libraries, but I needed to tweak them a 
bit to give the .so file a proper soname, which indicates that 
system-wide installation may be a bit of an afterthought.

> The latter bit adds an extra degree of freedom. What's the ABI stability of Skia like? Is it susceptible to Heisenbugs at the worst possible time (like libxml2...) or is it just as reasonable as usual for other packages to depend on the libskia package? I see libskia is available as a shared library which makes me optimistic about the latter. On the other hand https://skia.googlesource.com/skia/+/refs/heads/main/RELEASE_NOTES.md does show such changes as function removals.

> I see https://skia.org/docs/user/release/ says
>> We recommend most clients track our tip-of-tree as we work hard to keep it green. [...]
>> If you require less frequent updates, we cut a stable milestone every four weeks along with Chrome.
>> Chromium (and Skia) have a staged branching strategy. Every four weeks a branch is cut from a relatively stable revision near HEAD, is stabilized for six weeks, and then promoted to stable.
> (Is that still accurate? At https://chromiumdash.appspot.com/schedule it hints Chromium could be on a biweekly schedule now.)

You are right, they recently switched to a bi-weekly release schedule 
(which is one thing that made me re-think the situation). I suppose they 
have not updated that page yet.

As for API stability: the milestones are very stable (only backporting 
high-priority patches), but that does not matter too much as they are 
only active for two weeks. As upstream for storm-lang (the other user of 
libskia), I have updated the Skia version 2-3-times by now. Each time 
about a year of releases. Most parts of the API are the same, but each 
time there have been some (relatively small) details that I needed to 
change. For example, gradient fills moved from one place to another, and 
later changed what color parameter they received (to be explicit about 
color spaces, I think). A bit annoying, but small patches at the end of 
the day (I carried one such patch in storm-lang in Debian for a while). 
That being said, I think I am using a relatively small portion of the 
API there.

I am not familiar with the libxml2 situation, so I cannot say too much 
about it. My experience is that the API on a source level is 
well-designed enough to break when details are changed, so I am not 
worried about version mismatch causing issues. Given that it is C++, 
binary compatibility across such changes is another thing (e.g. removing 
a virtual function may cause vtables to mismatch). This is why I use the 
milestones for the so-version. Both the API and ABI are stable across 
milestones, but this will of course lead to more frequent soname bumps.

> In conclusion, I recognize there are difficult social factors at play. I am concerned about consequences for the free software movement with respect to fast-moving, "take it or leave it" projects (and I don't assert that Skia is one, but that's where my thoughts are headed so far). When code changes so frequently that no one who *isn't* a full-time employee of the producer can wrap their head around it, this creates some practical friction with the freedom to modify, share, and use the software. The challenge of keeping up with security issues for you could be an example. I don't have any idea what motivates you to work on the Skia package. Take care of yourself and set a boundary as you see fit: you owe no one an explanation for how you choose to spend your time contributing. If that means providing the libskia package primarily just for skia-pathops and asserting there is no security support, that'd be quite sensible.

Thank you for these thoughts - after reading them, I think they are a 
good summary of my own feelings as well. The high pace of development 
and CVEs makes it difficult to keep up. It is a bit sad - Skia is 
otherwise a good library. The reason I ended up with it for storm-lang 
was that I did not find any other hardware-accelerated 2D rendering 
library that fulfilled my needs at the time, and Skia seemed to be 
recommended almost as a de-facto standard. It seems skia-pathops is in a 
similar position, at least in some areas.

Thanks also for the note about boundaries. I think I was aiming a bit 
too high initially, especially given the importance of security work. I 
was in contact with Moritz (jmm) from the security team about this, and 
we ended up with something like your suggestion: providing libskia 
without security support for cases where that is acceptable (they were 
fine using it for storm-lang also, which is the main reason I packaged 
it initially).

(On a positive note, this entire situation inspired me to sketch out a 
custom OpenGL-based 2D renderer for storm-lang based on ideas from 
nanovg. It ended up being a quite fun thing to do! Maybe it will even be 
good enough to ship someday.)

Greetings,
   Filip

Back to linux.debian.security | Previous — Previous in thread | Find similar | Unroll thread

Thread

Feasibility to patch libskia moving forward Filip Strömbäck <fstromback@debian.org> - 2026-09-24 09:10 +0200
  Re: Feasibility to patch libskia moving forward Sylvain Beucler <beuc@beuc.net> - 2026-10-01 10:50 +0200
  Re: Feasibility to patch libskia moving forward Filip Strömbäck <fstromback@debian.org> - 2026-10-10 18:00 +0200

csiph-web