The icon "icon.svg" to be of type "text/plain". Only "image/jpeg, image/png, image/svg+xml" are allowed

[Merlijn Sebrechts]

I get a weird error when trying to push metadata.

$ snap download foliate --edge
$ snapcraft push-metadata foliate_82.snap
Pushing metadata from 'foliate_82.snap'
Received 415: 'The icon "icon.svg" to be of type "text/plain". Only "image/jpeg, image/png, image/svg+xml" are allowed.'

First discussed on the forum: https://forum.snapcraft.io/t/icon-svg-to-be-of-type-text-plain-only-image-jpeg-image-png-image-svg-xml-are-allowed/16425

I attached a download of the snap for future reference.

[Merlijn Sebrechts (merlijn-sebrechts)]

Note: the wording of the error message is a bit weird. This is a bit better:

> ERROR: The icon "icon.svg" is of type "text/plain". Only "image/jpeg, image/png, image/svg+xml" are allowed.

[Evgeny Vlasenko (mahnunchik)]

Any news?

[Daniel Manrique (roadmr)]

also need to update the api documentation to indicate that we look at content-type header to determine the type.

https://dashboard.snapcraft.io/docs/api/snap.html#get--dev-api-snaps-(snap_id)-binary-metadata

[Chris Patterson (cjp256)]

The culprit was identified to be an inaccurate identification of the file from the snap-store side. Daniel Manrique is aware and working the issue. Marked as invalid for Snapcraft, please re-open if we should make changes.

[Daniel Manrique (roadmr)]

ok, apologies, this does seem to all be store-centric. The store will NOT look at the incoming multipart form's mime type; rather it uses python-magic to determine file type by looking at the first 4096 bytes of the file.

This is in the devportal.forms.UpdateBinaryMetadataForm._detect_mime_type method.

I think snapcraft uses a different method of determining file type; another thing I found quickly poking at things is that python-magic 0.4.13 detects svg files as octet/stream or somesuch, not as svg. Python-magic 0.4.18, though, does detect correctly for the example given svg, even with only the first 4k of file.

So store-side:

1) update python-magic to 0.4.18
2) fix the awkward string to read more nicely :)

[Daniel Manrique (roadmr)]

The plot thickens -

the problem is not python-magic but the underlying libmagic which also powers the "file" command - on Xenial (which is the platform the store runs under), the given svg *IS* detected as text/plain:

$ file --mime-type src/testing/test_data/icon.svg
src/testing/test_data/icon.svg: text/plain

under Ubuntu 18.04 the library has been updated and works well:

$ file --mime-type /tmp/squashfs-root/meta/gui/icon.svg
/tmp/squashfs-root/meta/gui/icon.svg: image/svg

we cannot use Python's mimetypes library for two reasons: it can't operate on file-like objects, it requires an actual file; and, the reason it requires an actual file is because its type guessing is based on file extension, which is error-prone.

[Daniel Manrique (roadmr)]

One option is to configure a magic file that can identify svgs properly:

magician = magic.Magic(magic_file='magic.mgc')

The obvious and simplistic "copy a 18.04 magic.mgc file over to the Xenial unit" doesn't work because the underlying format changed and the magic files are not compatible.

[Daniel Manrique (roadmr)]

https://code.launchpad.net/~roadmr/software-center-agent/+git/software-center-agent/+ref/svg-detection has a failing test and data file demonstrating the problem. I think this is because faily svgs start as <svg and not as <?xml which old libmagic can't cope with.

[Daniel Manrique (roadmr)]

The magic file that can detect svg from upstream https://github.com/file/file still works with the libmagic version in xenial. So the easiest solution with only one extra "if", 3 extra lines of code and shipping only one small extra file with SCA:

1- Use a Magic instance pointing to the new svg-only libmagic file.
2- If that identifies the file as svg, return that.
3- If it's identified as something else (typically data), then fall back to the system-level / default libmagic.