Comment 4 for bug 1172961

I thought so too Francois, but after some research it looks like solution #1 won't solve the problem:

if a given format is registered in binfmts, and its magic or extension matches, it *will* be considered an executable *even* if all its detectors fail! A +x'ed zip or docx will still fail, the error message will be different, from "invalid file (bad magic number): Exec format error" to "run-detectors: unable to find an interpreter for file"

So, while solution #1 is an improvement for java, for preventing it to load 'java -jar file.docx', it would not solve this bug.

We are left with solution #2 (change binfmt from 'PK\...' magic to 'jar' extension) and #3 (do not install a binfmt at all). #2 seems reasonable, its only obvious (bit minor) drawback is requiring .jar files to be actually named '*.jar'

There is also another viable approach: #3, but instead of not installing the binfmt, install and *disable* it by default. This can be done with:

sudo --update-binfmts --disable jar

So the whole infrastructure would still be there for those who wanted it (preferably combined with #1), and this feature could be properly documented in java's documentation, explaining the consequences of enabling jar, and discussing alternatives. There can even be 2 binfmts, jar-extension and jar-magic, both disabled but easy to enable with a single command. User can make a well informed decision and choose either magic, extension or none.

Java fans would be 1 command away from re-enabling it, and the Ubuntu target user would happily open zip and docx files in wine apps with no errors or security risks.

Even with binfmt disabled, jar can still be directly executed (double-click in Nautilus, xdg-open, etc) via desktop associations. Which works out of the box by the way.

Win-win for me.

Do java maintainers / devs agree?