Re: [BUG] extfs: uzip script + password protected zip files

[Pavel Roskin <proski gnu org>]

Hello!

> If someone tries to view,extract,edit,etc a file from a password
> protected zip archive with MC the program will hang badly. MC doesnt
> hang actually but is waiting for unzip which waits the user to enter a
> password. I assume that this problem is also there for other archive
> formats which support password protection.

The problem is for any external software that can ask questions,
especially if it doesn't use stdin for that.

>        character (`T' or `B').
> 
> So if the uzip script is changed to inform the vfs layer that there is
> and encrypted file in the archive then the vfs layer should be modified
> aproapriately to handle the password input or just to fail further
> operations on the encrypted file.

There is no way to inform the VFS layer without changing VFS to keep this
attribute.  This is quite intrusive and very specific for archives (zip,
arj, rar).

> I haven't still looked at the code and I dont know if this is a task
> which can be completed fairly easy and without heavy modifications to
> the code.
> 
> Any thoughts ? Had someone tried in the past to fix this ? Any hints ?
> :)

1) Cheap workaround - check for T or B and if it's there, make a fake
file.  Put an explanation inside, like "mc: sorry, the file is encrypted".

2) Slightly more generic - intercept SIGTTIN in extfs.c and kill programs
trying to read from the keyboard.

3) Quite heavy, good for Java hackers, Mozilla theme editors etc -
integrate zip support into mc, just like tar and cpio.  Link mc with zlib.

4) The best and the hardest approach - integrate a terminal into mc, run
all external programs in separate terminals (so that the subshell is not
disturbed) and switch to the terminal when it requires attention, so that
the user can enter the password.

The number 4 is planned in the 4.7 branch (although I'm not sure if I'll
be able to work on it).  If you like any of simpler workaround, you are
welcome to try in the meantime.

-- 
Regards,
Pavel Roskin