Ticket #4180 (reopened defect)

Opened 5 weeks ago

Last modified 5 days ago

mc 4.8.26: cannot view content of .xpi archives (firefox extensions, aka zip files with .xpi extension)

Reported by: gv Owned by: andrew_b
Priority: major Milestone: 4.8.27
Component: mc-core Version: master
Keywords: Cc: ossi, jg.staffel@…, onlyjob@…
Blocked By: Blocking:
Branch state: on review Votes for changeset:

Description

Up to mc 4.8.25 you can view the content of firefox extensions (.xpi files). This is not possible anymore.

The error message is:

Cannot open "/path/to/ff_ext.xpi" in parse mode
No such file or directory (2)

If I renaming .xpi archive to .zip , mc display the content just fine:

$ file ff_ext.xpi 
ff_ext.xpi: Zip archive data, at least v1.0 to extract
$ cp ff_ext.xpi ff_ext.zip
$ file ff_ext.zip
ff_ext.zip: Zip archive data, at least v1.0 to extract

F3 on ff_ext.zip display list of files in the archive.

However:

$ zip archive some-dummy-file.txt 
  adding: some-dummy-file.txt (deflated 66%)
$ file archive.zip 
archive.zip: Zip archive data, at least v2.0 to extract

F3 on archive.zip display list of files in the archive.

$ cp archive.zip archive.xpi

F3 on archive.xpi and mc display the content of some-dummy-file.txt instead of archive filename list.

$ zip archive1 some-dummy-file.txt another-dummy-file.txt
  adding: some-dummy-file.txt (deflated 66%)
  adding: another-dummy-file.txt (deflated 66%)
$ file archive1.zip 
archive1.zip: Zip archive data, at least v2.0 to extract
$ cp archive1.zip archive1.xpi

F3 on archive1.xpi and the same message is shown:

Cannot open "/path/to/archive1.xpi" in parse mode
No such file or directory (2)

Change History

comment:1 follow-up: ↓ 2 Changed 5 weeks ago by andrew_b

  • Cc ossi added
  • Owner set to andrew_b
  • Status changed from new to accepted
  • Component changed from mc-vfs to mc-core
  • Branch state changed from no branch to on review

This is the result of #4128. You should synchronize your local ~/.config/mc/mc.ext with system-wide /etc/mc/mc.ext.

As a quick workaround, you can change one line in your mc.ext:

  • mc.ext

    old new  
    751751       View=%view{ascii} /usr/libexec/mc/ext.d/archive.sh view zip 
    752752 
    753753# zip 
    754 type/i/^zip\ archive 
     754type/\(Zip archive 
    755755       Open=%cd %p/uzip:// 
    756756       View=%view{ascii} /usr/libexec/mc/ext.d/archive.sh view zip 

Branch: 4180_mc.ext_zip_regex
changeset:7881ed2fda7390d3821abd6864d0097fc818f0ac

comment:2 in reply to: ↑ 1 Changed 5 weeks ago by gv

Sorry, but there is no mc.ext in ~/.config/mc. Instead I changed /etc/mc/mc.ext.

Still, I get the same error message. After the dialog is dismissed, mc show the raw content of the archive (the same you get with Shift-F3) instead of the list of files in the archive. Pressing enter on the xpi file does nothing.

comment:3 Changed 5 weeks ago by andrew_b

Sorry, I cannot reproduce that. Please check your files again.

comment:4 Changed 5 weeks ago by gv

I did not quit mc after I changed mc.ext. It works fine now.

Thank you.

comment:5 Changed 4 weeks ago by andrew_b

Ticket #4183 has been marked as a duplicate of this ticket.

comment:6 Changed 4 weeks ago by andrew_b

  • Votes for changeset set to gv andrew_b
  • Branch state changed from on review to approved

comment:7 Changed 4 weeks ago by andrew_b

  • Status changed from accepted to testing
  • Votes for changeset changed from gv andrew_b to committed-master
  • Resolution set to fixed
  • Branch state changed from approved to merged

comment:8 Changed 4 weeks ago by andrew_b

  • Status changed from testing to closed

comment:9 Changed 8 days ago by alpir

  • Status changed from closed to reopened
  • Resolution fixed deleted

After applying the patch, zip archives began to open, but open with an error:

file -L -z archive.zip: Bad system call

This caused by using /usr/bin/file with -z option (src/filemanager/ext.c), because seccomp doesn't allow it. The problem is seccomp, a security sandbox. Security is more important than usability, so if we actually need -z, we should generally also use -S.

comment:10 Changed 8 days ago by alpir

  • Cc jg.staffel@… added

comment:11 Changed 8 days ago by ossi

my manual contains this nice blurb:

Note: This Debian version of file was built without seccomp support, so this option has no effect.

which is why i never noticed that this option was introduced at some point.

i'll note that a sandbox that cripples the host program is somewhat "sub-par". a proper implementation would use a non-sandboxed helper process for spawning essential children (which would ideally run inside a sandbox in turn).

i suppose adding -S is the way forward.

comment:12 Changed 8 days ago by alpir

Gentoo x64,sys-apps/file-5.39-r3 has default USE flag seccomp. As far as I know, file is also built with this option in Arch.

comment:13 Changed 8 days ago by onlyjob

  • Cc onlyjob@… added

comment:14 Changed 8 days ago by andrew_b

  • Votes for changeset committed-master deleted
  • Version changed from 4.8.26 to master
  • Branch state changed from merged to on review

comment:15 Changed 8 days ago by ossi

i'd swap the use order of FILE_L and FILE_S, as -S is related to -z.
also, the else-branches in the AC_DEFINEs should use empty strings, not spaces.

comment:16 Changed 8 days ago by ossi

on a mildly related note, it would probably make sense to also check for -z, and just error out if that fails (as implementing an alternative path for that seems kinda impractical).

comment:17 Changed 7 days ago by andrew_b

[ec1938db8ef8171440e1a56aea94feec59d23f71]

If file doesn't accept the -z options, it unused at all.

comment:18 Changed 7 days ago by ossi

not reviewed in context and not tested, but what i see looks good.
fwiw, there is an excess space on line 134 after the comma.

comment:19 Changed 5 days ago by andrew_b

Ticket #4208 has been marked as a duplicate of this ticket.

Note: See TracTickets for help on using tickets.