allow utf-8 header for svg detection #2481
Conversation
We were checking that the first 24 chars of an SVG were plain ASCII, but that's not always the case, for example: <svg id="レイヤー_1のコピー" data-name="レイヤー 1のコピー" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100"> </svg> We now test for the string "<svg" being in the first 1000 bytes, and everything up to that being valid utf-8. See #2438
we could have read a byte or two after the end of the string if haystack ended in part of needle and a utf-8 character straddled the boundary
|
It's failing on this webp: https://github.com/libvips/libvips/blob/master/test/test-suite/images/looks-like-svg.webp A webp files that happens to contain the characters Perhaps we should check all the first 1000 bytes are valid utf-8? @lovell, any thoughts? |
|
Alternatively, we could increase the priority of webpload, as that only needs to sniff 12 bytes from the header. libvips/libvips/foreign/webpload.c Lines 169 to 171 in e1a7063 libvips/libvips/foreign/webp2vips.c Line 321 in e1a7063 |
|
Are we sure that WebP image is valid UTF-8 up until the $ head -c 588 looks-like-svg.webp | iconv -f UTF-8
RIFF(
WEBPVP8X
iconv: illegal input sequence at position 24 |
|
Ooof, you were right Lovell, it was my fault, you can't test for I've raised the priority of webpload as well -- as you say Kleis, it's very quick (much faster than svgload), so it should be near the top. It was on a very low priority before, perhaps we used to use a slow sniffer for it? Anyway, it seems to work now! |
it was very low priority before, for some reason
|
Note that OSS-Fuzz does not currently build against librsvg, so this change is not covered. I've looked into this in the past, but it requires adding these (sub-)dependencies as well: Dependency-graph librsvg
|
|
@kleisauke Good spot, I can take a look at adding it. To start with we might be able to get away using apt to install some/all of these rather than build from source. |
We were checking that the first 24 chars of an SVG were plain ASCII,
but that's not always the case, for example:
We now test for the string "<svg" being in the first 1000 bytes, and
everything up to that being valid utf-8.
See #2438