Ticket #1685 (accepted defect)

Opened 10 years ago

Last modified 5 months ago

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

Reported by: igorp1024 Owned by: zaytsev
Priority: major Milestone: 4.8.24
Component: mc-vfs Version: master
Keywords: Cc: tux@…
Blocked By: Blocking:
Branch state: no branch Votes for changeset:

Description (last modified by andrew_b) (diff)

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

Attachments

compressed_encryption_fix.patch (1.3 KB) - added by congest 3 years ago.
encrypted.rar (132 bytes) - added by congest 3 years ago.
encrypted.zip (210 bytes) - added by congest 3 years ago.
unencrypted.rar (96 bytes) - added by congest 3 years ago.
unencrypted.zip (182 bytes) - added by congest 3 years ago.

Change History

comment:1 Changed 10 years ago by andrew_b

  • Component changed from mc-core to mc-vfs

comment:2 Changed 10 years ago by bilbo

  • Cc tux@… added

comment:3 Changed 10 years ago by Spinal

  • Version changed from 4.7.0-pre3 to 4.7.0
  • Milestone changed from 4.7 to 4.7.1

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

comment:4 Changed 10 years ago by andrew_b

  • Milestone changed from 4.7.1 to 4.7

comment:5 follow-up: ↓ 6 Changed 9 years ago by eugenesan

  • Milestone changed from 4.7 to 4.7.5
  • Version changed from 4.7.0 to 4.7.4
  • Summary changed from Incorrect handling of rar-archives with encrypted headers (-hp option) to Missing support for archives with encrypted headers (rar, 7z and probably more)

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

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

comment:6 in reply to: ↑ 5 Changed 9 years ago by andrew_b

  • Description modified (diff)
  • Milestone changed from 4.7.5 to 4.7

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?

comment:7 follow-up: ↓ 8 Changed 9 years ago by 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.

comment:8 in reply to: ↑ 7 ; follow-up: ↓ 9 Changed 9 years ago by 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.

comment:9 in reply to: ↑ 8 ; follow-up: ↓ 10 Changed 9 years ago by 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.

comment:10 in reply to: ↑ 9 Changed 9 years ago by 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.

comment:11 Changed 8 years ago by andrew_b

  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases

comment:12 Changed 6 years ago by 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'). (But only for the extraction/list commands, because we don't want to add files into the archive using this dummy password.)

Last edited 6 years ago by mooffie (previous) (diff)

comment:13 Changed 6 years ago by ForeverYoung

Why not just use this workaround for now?

Changed 3 years ago by congest

comment:14 Changed 3 years ago by 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.

comment:15 Changed 3 years ago by 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...

comment:16 Changed 3 years ago by zaytsev

  • Owner set to zaytsev
  • Status changed from new to accepted
  • Version changed from 4.7.4 to master
  • Milestone changed from Future Releases to 4.8.20

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?

Changed 3 years ago by congest

Changed 3 years ago by congest

Changed 3 years ago by congest

Changed 3 years ago by congest

comment:17 Changed 3 years ago by congest

I attached encrypted and unencrypted rars and zips.

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

comment:18 Changed 2 years ago by zaytsev

  • Milestone changed from 4.8.20 to 4.8.21

comment:19 Changed 18 months ago by zaytsev

  • Milestone changed from 4.8.21 to 4.8.22

comment:20 Changed 11 months ago by zaytsev

  • Milestone changed from 4.8.22 to 4.8.23

comment:21 Changed 6 months ago by 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.

comment:22 Changed 5 months ago by zaytsev

  • Milestone changed from 4.8.23 to 4.8.24
Note: See TracTickets for help on using tickets.