shared-mime-info endianness issue

[David Faure]

The magic for application/x-java-keystore says
<match type="host32" value="0xfeedfeed" offset="0"/>

And the test file test.jks starts with 0xFE, 0xED, 0xFE, 0xED.
On a little-endian machine this leads to a value of 0xedfeedfe
when read as a single 32-bit value.

So this does not match. Am I missing something?

I found this with an implementation which does not go through mime.cache but
reads directly from the XML, so the fact that xdgmime works on this file might
indicate a bug related to the mime.cache intermediary?

http://mindprod.com/jgloss/cacerts.html says "The first four signature bytes of
a Sun cacerts file in hex are FEEDFEED." so I wonder if this rule should say
big32 instead of host32. With big32, both the s-m-i testsuite and my
implementation (which uses the same testsuite) pass.

Everything else passes, which makes me wonder if this is the only "host" match
actually used by the test suite ;)
Actually, if it's not, then I have to assume the test suite is known broken on
big-endian machines, given that any "host" match would fail there, unless we
put two versions of the file in the testsuite (one generated for little-endian
machines and one generated for big-endian machines). But apparently this isn't
needed yet, if I'm right that the java keystore magic should say big32.

[Thiago Macieira]

Em segunda-feira, 26 de dezembro de 2016, às 13:35:33 BRST, David Faure

Post by David Faure
Everything else passes, which makes me wonder if this is the only "host"
match actually used by the test suite
Actually, if it's not, then I have to assume the test suite is known broken
on big-endian machines, given that any "host" match would fail there,
unless we put two versions of the file in the testsuite (one generated for
little-endian machines and one generated for big-endian machines). But
apparently this isn't needed yet, if I'm right that the java keystore magic
should say big32.

Obviously, tests that need host-specific matching require host-specific files
too. So we need to have duplicated files for each and every detection that has
"host," which wil also help us confirm whether these files are valid or not.

A testsuite can be built in "other endinanness" mode to verify that it works
too.

[Bastien Nocera]

Post by David Faure
The magic for application/x-java-keystore says
<match type="host32" value="0xfeedfeed" offset="0"/>
And the test file test.jks starts with 0xFE, 0xED, 0xFE, 0xED.
On a little-endian machine this leads to a value of 0xedfeedfe
when read as a single 32-bit value.
So this does not match. Am I missing something?
I found this with an implementation which does not go through
mime.cache but 
reads directly from the XML, so the fact that xdgmime works on this
file might 
indicate a bug related to the mime.cache intermediary?
http://mindprod.com/jgloss/cacerts.html says "The first four
signature bytes of 
a Sun cacerts file in hex are FEEDFEED." so I wonder if this rule
should say 
big32 instead of host32. With big32, both the s-m-i testsuite and my 
implementation (which uses the same testsuite) pass.
Everything else passes, which makes me wonder if this is the only
"host" match 
actually used by the test suite ;)
Actually, if it's not, then I have to assume the test suite is known
broken on 
big-endian machines, given that any "host" match would fail there,
unless we 
put two versions of the file in the testsuite (one generated for
little-endian 
machines and one generated for big-endian machines). But apparently
this isn't 
needed yet, if I'm right that the java keystore magic should say big32.

This looks like a straight up bug in the definition.

Given that the test suite only runs from git checkouts, and that
developers with big endian machines are pretty thin on the ground, this
likely never got tested.

Feel free to file a bug and attach a patch for those wrong definitions.

Cheers

[David Faure]

Post by Bastien Nocera

Post by David Faure
The magic for application/x-java-keystore says
<match type="host32" value="0xfeedfeed" offset="0"/>
And the test file test.jks starts with 0xFE, 0xED, 0xFE, 0xED.
On a little-endian machine this leads to a value of 0xedfeedfe
when read as a single 32-bit value.
So this does not match. Am I missing something?
I found this with an implementation which does not go through mime.cache but
reads directly from the XML, so the fact that xdgmime works on this file might
indicate a bug related to the mime.cache intermediary?
http://mindprod.com/jgloss/cacerts.html says "The first four
signature bytes of
a Sun cacerts file in hex are FEEDFEED." so I wonder if this rule should say
big32 instead of host32. With big32, both the s-m-i testsuite and my
implementation (which uses the same testsuite) pass.
Everything else passes, which makes me wonder if this is the only "host" match
actually used by the test suite ;)
Actually, if it's not, then I have to assume the test suite is known broken on
big-endian machines, given that any "host" match would fail there, unless we
put two versions of the file in the testsuite (one generated for little-endian
machines and one generated for big-endian machines). But apparently this isn't
needed yet, if I'm right that the java keystore magic should say big32.

This looks like a straight up bug in the definition.

We agree, but that means there's also a bug in the reference implementation,
because it should NOT match test.jks, and it does.

Post by Bastien Nocera
Given that the test suite only runs from git checkouts, and that
developers with big endian machines are pretty thin on the ground, this
likely never got tested.

Sure. But the fact that it passes on a little endian machine given the broken
definition, looks to me like a bug in update-mime-database or in xdgmime.
Any chance you can look into it ? I'm not great at reading glib code...

Post by Bastien Nocera
Feel free to file a bug and attach a patch for those wrong definitions.

OK will do (I also have push access, but reviews are good)

Thanks,

[Bastien Nocera]

Post by David Faure

Post by Bastien Nocera

Post by David Faure
The magic for application/x-java-keystore says
<match type="host32" value="0xfeedfeed" offset="0"/>
And the test file test.jks starts with 0xFE, 0xED, 0xFE, 0xED.
On a little-endian machine this leads to a value of 0xedfeedfe
when read as a single 32-bit value.
So this does not match. Am I missing something?
I found this with an implementation which does not go through
mime.cache but 
reads directly from the XML, so the fact that xdgmime works on this
file might 
indicate a bug related to the mime.cache intermediary?
http://mindprod.com/jgloss/cacerts.html says "The first four
signature bytes of 
a Sun cacerts file in hex are FEEDFEED." so I wonder if this rule
should say 
big32 instead of host32. With big32, both the s-m-i testsuite and my 
implementation (which uses the same testsuite) pass.
Everything else passes, which makes me wonder if this is the only
"host" match 
actually used by the test suite ;)
Actually, if it's not, then I have to assume the test suite is known
broken on 
big-endian machines, given that any "host" match would fail there,
unless we 
put two versions of the file in the testsuite (one generated for
little-endian 
machines and one generated for big-endian machines). But
apparently
this isn't 
needed yet, if I'm right that the java keystore magic should say big32.

This looks like a straight up bug in the definition.

We agree, but that means there's also a bug in the reference
implementation, 
because it should NOT match test.jks, and it does.

Post by Bastien Nocera
Given that the test suite only runs from git checkouts, and that
developers with big endian machines are pretty thin on the ground, this
likely never got tested.

Sure. But the fact that it passes on a little endian machine given
the broken 
definition, looks to me like a bug in update-mime-database or in xdgmime.
Any chance you can look into it ? I'm not great at reading glib code...

I never tried to understand this code, or the binary cache format,
Matthias is the maintainer of it as far as I'm concerned.

Post by David Faure

Post by Bastien Nocera
Feel free to file a bug and attach a patch for those wrong
definitions.

OK will do (I also have push access, but reviews are good)

I usually review patches :)

[David Faure]

Post by Bastien Nocera
Feel free to file a bug and attach a patch for those wrong definitions.

Done: https://bugs.freedesktop.org/show_bug.cgi?id=99328