Missing support for archives with encrypted headers (rar, 7z and probably more)

[igorp1024]

If rar archive is packed with option '-hp' midnight commander stalls on open attempt of such archive. The only workaround is to do:
killall rar (if F3 was pressed)
killall unrar (if Enter was pressed)
After killing the rar/unrar process the "enter password ..." prompt is shown which is left from rar-process.
For testing purposes it is necessary to create archive with the following sample command:
$ rar a test_archive.rar * -hpmypassword

[Spinal]

I can confirm this behaviour.
Just tried to open encrypted archive and got stalled mc session.

[eugenesan]

Also affects 7z and probably most archivers with encrypted headers.

As solution dialog requesting for password should be added on such archives.

[andrew_b]

Replying to eugenesan:

As solution dialog requesting for password should be added on such archives.

What is your proposal, how to recognize that archive program asks password?

[birdie]

The only solution is to completely rework VFS and allow pluggable binary .SO modules which can read, parse and interact with a user (this is already implemented for tar and CPIO archives).

Currently implemented shell/perl scripts for managing archives are just gimmicks and will probably never allow a good level of compatibility and performance.

[andrew_b]

Replying to birdie:

this is already implemented for tar and CPIO

tar is scheduled to be reimlemented. Some internal mc utility and system tar will be used.
cpio is needed to be reimplemented too.

[birdie]

Replying to andrew_b:

Replying to birdie:

this is already implemented for tar and CPIO

tar is scheduled to be reimlemented. Some internal mc utility and system tar will be used.
cpio is needed to be reimplemented too.

Do I understand you correctly that you in fact want to get rid of CPIO and TAR binary parsers and turn them into auxiliary scripts which use the corresponding system applications?

That's very disappointing if that's true.

Try to enter an archive which contains tens of thousands of files. Right now MC will enter such CPIO/TAR archives almost instantly, while for all other archive formats it will take considerable time.

Another problem we have to cope with auxiliary scripts is that some archivers often contain arbitrary file names which are incorrectly parsed/not parsed at all, thus you can end up not opening an archive at all or being unable to extract a particular file from an archive.

Parsing archivers textual output will never work reliably, nor fast.

[andrew_b]

Replying to birdie:

Do I understand you correctly that you in fact want to get rid of CPIO and TAR binary parsers and turn them into auxiliary scripts which use the corresponding system applications?

Yes.

That's very disappointing if that's true.

Do not make hasty conclusions

while for all other archive formats it will take considerable time.

That will be fixed in #3.

Parsing archivers textual output will never work reliably, nor fast.

Nobody wants reimplement extfs plugins from shell/python/perl sctipts to binaries.

[mooffie]

A workaround:

For rar, we can use the '-p-' switch ("Do not query password").
For 7z, we can unconditionally provide a dummy password ('-pdummy').

[ForeverYoung]

Why not just use this workaround for now?

[congest]

This bug has been around for many years. I just made a simple patch.

I only fixed the problem for rar and zip formats, since 7zr seems to crash when you try to do anything involving passwords.

[zaytsev]

I'm of the mind that we should commit the workaround for now if it doesn't have other bad side effects.

congest, could you please be so kind to provide dummy archives (rar, zip, 7z) with and without password protection, so that I can test your patch?

Also, I'm wondering whether what applies to 7zr also applies to 7z & 7za. Our helper prefers them if they exist. Maybe it's worth "fixing" 7z helper by adding an empty password only if command is NOT 7zr if 7z & 7za don't crash?

Finally, if reliably reproducible, maybe need to report a bug against 7zr...

[zaytsev]

​http://manpages.ubuntu.com/manpages/zesty/man1/7z.1.html
​http://manpages.ubuntu.com/manpages/zesty/man1/7za.1.html

       -p{Password}
              Set Password (NOTE: this flag does not work with 7z,

WTF this is supposed to mean?

​http://manpages.ubuntu.com/manpages/zesty/man1/7zr.1.html

       7zr  is  a stand-alone executable.  7zr is a "light-version" of 7za(1).
       7zr handles password-less archives in the 7z,  LZMA2,  and  XZ  formats
       only.

So the flag doesn't even exist for 7zr?

[congest]

I attached encrypted and unencrypted rars and zips.

I guess 7zr is just not meant to handle encrypted files.

[anton_kg]

It is sad to see that such a useful feature is still not in MC after 10 years of this bug being reported.

Can you copy the code from ​https://github.com/FarGroup/FarManager if possible or implement a better one? 7z is universal unpacker and open source too. You can just copy the relevant code if calling cli tool is not a good option.

[LeXofLeviafan]

Current status (v4.8.28)

• For encrypted.zip & encrypted.rar archives attached to the ticket (as well as an old 7Z archive I had on my filesystem):
  • Trying to preview (F3) or open (Enter) the ZIP archive seems to work fine (no password is requested).
  • Trying to extract (F5) a file from opened ZIP archive results in an error that shows “EXTFS virtual file system:”, archive file name, name of selected file in archive, “password:”… and then for some reason it appears to be listing directory history of both panels (starting from somewhere in the middle of a random entry, and continuing down beyond the screen border); the error refuses to close as MC seems to have stopped accepting any input (until I kill unzip, then it closes on Enter, and an empty file is extracted).
  • Trying to view (F3) the same file from opened ZIP archive results in the same error, except now it spans both up and down beyond the screen border (it refuses to go away until unzip is killed, then it shows an empty file). Sometimes this error doesn't include an excerpt from the directory history of the panels, though.
  • Trying to preview a RAR file shows an error message containing the “enter password …” text which is randomly cut off; Enter closes the error and shows output of unrar with the text Program aborted in place of file list.
  • Trying to open the same RAR file shows the same error in full (but with randomly inserted linebreaks) which then gets temporarily disabled (closed with Enter); both on this and subsequent attempts it shows archive contents as an empty folder.
  • Trying to preview a 7Z archive hangs up MC (until I kill 7za, then an error is shown but it refuses to close; terminating 7za instead doesn't result in an error but MC still refuses to accept any input until I kill 7z – after that the output for both commands is shown, both ending on “enter password” line).
  • Trying to open a 7Z archive hangs up MC (until I kill or terminate 7z, then it shows an empty archive).
• For archives produced by me just now (created using zip, rar and 7z commands with password supplied) it's somewhat different:
  • Trying to preview or open any of the new archives seems to work fine.
  • Trying to extract or view a file from a ZIP archive works the same as for the attached ZIP file
  • Trying to extract or view a file from a RAR archive produces no error but no password is requested and the extracted file is empty.
  • Trying to extract a file from a 7Z archive pops up a copy dialogue but the progress is stuck at 0% and MC no longer seems to accept any input (killing 7z results in the dialogue being closed, but the extracted file is empty).
  • Trying to view a file from a 7Z archive freezes MC (killing 7z unfreezes it, then an empty file is shown).

…Also, after a command that causes MC to freeze is killed, the copy dialogue becomes very glitchy (i.e. typing anything adds the character twice, with backspace only removing half of it; and pressing any navigation key leaves a character in the wake of the cursor, which also moves the cursor to the right).

[andrew_b]

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