Dear Security Team,
I am the maintainer of libskia. Soon after packaging the library, bug
#1134991 was filed, highlighting the importance of addressing CVEs. I
have since then figured out how to find patches from upstream and have
tried to keep up, but as you are aware there are many CVEs filed against
Skia through chrome.
So far I have managed to keep up, backporting 50+ fixes so far. However,
with the new release cadence (2 weeks for new milestones), and the high
velocity of development, it makes patches increasingly difficult to
backport. The last 3 CVEs have patches to parts of the codebase that did
not exist in the packaged version (most likely: refactors have moved
things around, the issue is likely somewhere else). So with the cadence
of CVEs and code changes, it is not feasible for me to backport fixes. I
did a slightly longer writeup on the debian-fonts list [0].
In short, I am currently considering what the best way forward is, and I
would like your input.
One option would be to drop it. Since the package is fairly new, the
impact is not too large (but still sad, the fonts-team uses skia-pathops
to build some fonts).
Another would be to make it explicit that it is not possible to do the
security work on it, like [1]. I see some other web renderers there, so
it might be possible. Then libskia could be updated for each stable
version like many other libraries. Of course, that means that chromium
should not use libskia (which I don't think it can regardless, building
a new chromium with an older Skia will not be fun, nor necessarily
secure). But at least it could be used to build fonts for the system.
(The dependency from storm-lang could be dropped, making remaining
dependencies only use pathops).
I would be happy to hear your thoughts on this matter!
Thanks,
Filip
[0] https://lists.debian.org/debian-fonts/2026/09/msg00239.html
[1]
https://salsa.debian.org/debian/debian-security-support/-/blob/master/security-support.deb13
