Created attachment 128821 [details] [review] freedesktop.org.xml.in.diff 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. http://mindprod.com/jgloss/cacerts.html says "The first four signature bytes of a Sun cacerts file in hex are FEEDFEED." so I think 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. Please review.
We require git-formatted patches. (In reply to David Faure from comment #0) > Created attachment 128821 [details] [review] [review] > freedesktop.org.xml.in.diff <snip> > 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. You could show instead of telling, by showing the output of "hexdump" > http://mindprod.com/jgloss/cacerts.html says "The first four signature bytes > of a Sun cacerts file in hex are FEEDFEED." so I think 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. This isn't a canonical page for Sun cacerts. Going to the front page of the site makes that clear.
Created attachment 128825 [details] [review] git-formatted patch
git-formatted: heh, yeah, catch 22, I needed the bugzilla URL to put into the commit log ;-) Attaching new patch now. `hexdump ./tests/test.jks` uses a word size of 32 bits, leading to confusing output. But hexdump -C is clear: hexdump -C ./tests/test.jks 00000000 fe ed fe ed 00 00 00 02 00 00 00 00 57 be bc 27 |............W..'| I know the URL I found isn't "official", but I didn't find anything else on the topic. Tell me if you find better ;-) The point is that it confirms what we actually have in test.jks, whereever that came from (unless the website is wrong/unclear AND the test file came from a big endian machine, of course...).
(In reply to David Faure from comment #2) > Created attachment 128825 [details] [review] [review] > git-formatted patch Can you please add the explanation from comment 0, with the fixes mentioned in comment 2 to the commit log?
(In reply to David Faure from comment #3) > git-formatted: heh, yeah, catch 22, I needed the bugzilla URL to put into > the commit log ;-) git bz file ... :)
(In reply to David Faure from comment #3) > I know the URL I found isn't "official", but I didn't find anything else on > the topic. Tell me if you find better ;-) > The point is that it confirms what we actually have in test.jks, whereever > that came from (unless the website is wrong/unclear AND the test file came > from a big endian machine, of course...). I found this is the magic file: 0 belong 0xfeedfeed Java KeyStore which is a better reference than the URL you gave.
No idea what "git bz" is, must be some additional script ;) Thanks for the idea of looking into 'magic' from file(1), good to see that it confirms my suspicion. Attaching new patch.
Created attachment 128827 [details] [review] 0001-Fix-magic-for-application-x-java-keystore-to-say-big.patch
Committed with some changes to the commit message.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.