Bug#1064574: file-roller: 7zip can't handle encrypted archives with encrypted file names

[Richard]

Package: file-roller
Version: 43.1-1
Severity: important

Dear Maintainer,
it seems the version of file-roller is partially broken, possibly due to the
fact that it still lists p7zip-full as dependency and not the new 7zip
package
and thus might be missing some adaptation. Maybe some behavior of the 7z
interface has changed, I can't tell. I can only tell that file-roller is
incapable of opening and extracting encrypted 7zip archives that have their
file names encrypted as well. The 7z CLI from the 7zip package can do so
with
no issues, so it seems to be an issue with file-roller. At least, I think
it was
capable of handling this kind of archives before p7zip was replaced by 7zip.

The issue shows itself in the form that when trying to open such a file with
file-roller, it doesn't ask for a password, but only shows an empty screen.
You
can select "extract", but it will fail with a message that the extraction
couldn't be performed. Sadly, I have yet to be able to collect any kind of
logs.


-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (50, 'experimental'), (50, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages file-roller depends on:
ii 7zip [p7zip-full] 23.01+dfsg-8
ii bzip2 1.0.8-5+b2
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4+b1
ii libarchive13 3.7.2-1
ii libc6 2.37-15
ii libcairo2 1.18.0-1+b1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1
ii libglib2.0-0 2.78.4-1
ii libgtk-3-0 3.24.41-1
ii libhandy-1-0 1.8.3-1
ii libjson-glib-1.0-0 1.8.0-2
ii libnautilus-extension4 45.2.1-4
ii libpango-1.0-0 1.51.0+ds-4
ii p7zip-full 16.02+transitional.1

Versions of packages file-roller recommends:
ii gvfs 1.53.90-2
ii yelp 42.2-1+b1

Versions of packages file-roller suggests:
ii arj 3.10.22-26
ii lhasa [lha] 0.4.0-1+b1
ii lzip 1.24-1
ii lzop 1.04-2
pn ncompress <none>
ii rpm2cpio 4.18.2+dfsg-1
pn rzip <none>
pn sharutils <none>
ii squashfs-tools 1:4.6.1-1
ii unace 1.2b-23
ii unalz 0.65-9
ii unar 1.10.7+ds1+really1.10.1-2+b3
ii unzip 6.0-28
ii xz-utils [lzma] 5.4.5-0.3
ii zip 3.0-13
pn zoo <none>

-- no debconf information

[Mina]

Control: found -1 43.0-1

Hi
i had the same problem too i came here to open a bug but apparently you did it

i am on bookworm
file-roller version 43.0-1
i don't know why this problem happening am open to provide any logs

[Mina]

hi
i removed 7zip package from my system and it worked most probably
file-roller act differently when 7zip package is installed of course
ideally i would prefer using 7zip and
i think it's solved in upstream i tested it on opensuse tumbleweed and
the problem didn't happen although it wasn't consistent results i need
to make sure on that

if that the case i guess a patch could be backported to the next
stable point release if that possible

for now the steps to produce on Debian Bookworm :
- install 7zip package
- make encrypted 7z file with encrypted filenames PS: you have to
enter a password don't leave it empty
- try to open the file with file-roller it would give you an empty windows
- remove the 7zip package
- try opening again it will word