Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Since latest update, when trying to open .7zip pass encrypted files, it is
impossible to access files inside the .7zip file.


If you try to use 7za or 7zz vía command line, the file can be decompress after
typing the password. So, the files are correct.

Maybe the change from p7zip to 7zip packages could have something to do here.


Thank you.

**Engrampa/LXQt Archiver doesn't handle password-protected 7z files
correctly in Debian 12/13: empty archive with `-mhe=on` and incorrect
opening with `-mhe=off`**

## Summary

In Debian 12, the graphical archivers `Engrampa` and `lxqt-archiver`
exhibit incorrect behavior with password-protected `.7z` files created
with `7zip`/`7zz`. When the 7z archive contains only encrypted content
(`-mhe=off`), the archiver displays the file list, but double-clicking
attempts to open the files without prompting for a password and fails.
When the header/listing is also encrypted (`-mhe=on`), the archiver
opens the file as empty and doesn't prompt for a password. Extraction
from the console using `7za` or `7zz` works correctly in both cases.
[mail-archive](https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg2047228.html)

## Environment

- System: Debian 12.
- Affected application: `engrampa` 1.26.0-1+deb12u2.
- Also reproducible with `lxqt-archiver`.
- Tested console tool: `7za` and `7zz` work correctly.
- Installed compression package: `7zip` 25.01+dfsg-1~deb13u1+bpo12+1.

## Steps to reproduce

### Case A: Encrypted content, unencrypted headers

7z to test-off.7z folder_or_file -p'MyPassword123' -mhe=off



1. Open `test-off.7z` with Engrampa or lxqt-archiver.

2. The internal files are displayed.

3. Double-click on one of them.

### Observed result

The file manager attempts to open the file without prompting for a
password, and the content is not displayed correctly.

### Expected result

Upon double-clicking, the password should be requested before attempting
to open or extract the file.

***

### Case B: Encrypted Content and Headers


7z to test-on.7z folder_or_file -p'MyPassword123' -mhe=on


1. Open `test-on.7z` with Engrampa or lxqt-archiver.

2. The archive appears empty or without a contents list.

3. No password prompt appears.

### Observed Result

The file appears empty and no password is requested.

### Expected Result

The password should be requested when opening the file, or at least a
coherent dialog should be displayed that allows the contents list to be
decrypted.

## Expected Behavior

Graphic archivers should:

- Request the password when opening an encrypted `.7z` file.

- Correctly handle both files with visible headers (`-mhe=off`) and
those with encrypted headers (`-mhe=on`).

- Do not attempt to open an internal file without authenticating the
operation.

- Do not display the file as empty if the container is protected with an
encrypted header.

## Actual Behavior

- With `-mhe=off`, the listing appears, but opening the internal file
fails because no password is requested.

- With `-mhe=on`, the listing does not appear, and the file is displayed
as empty.

- The command line works correctly, indicating that the file is valid
and the problem lies in the graphical integration.
[bugzilla.xfce](https://bugzilla.xfce.org/show_bug.cgi?id=4116)

## Technical Evidence

This behavior matches bugs previously described in other archiving
frontends when handling 7z files with an encrypted header (`-mhe=on`),
where the application fails to list the contents or request the password
when opening the file. There are also recent reports from Engrampa
indicating problems with password-protected 7z files and/or encrypted
filenames, with fixes already available in the source code but not
necessarily included in distributed packages.
[github](https://github.com/mate-desktop/engrampa/issues/510)

## Impact

This breaks the normal workflow with protected `.7z` files, especially
if encrypted headers are used for privacy reasons. In desktop
environments, users expect the graphical archiver to prompt for the
password transparently, or at least not hide the file as empty.
[mail-archive](https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg2047228.html)

## Test Commands

### Create archive with only encrypted content

7z a test-off.7z folder/ -p'MyKey123' -mhe=off


### Create archive with encrypted content and header

7z a test-on.7z folder/ -p'MyKey123' -mhe=on


### Verify from console

7zz l test-off.7z
7zz l test-on.7z
7zz x test-off.7z
7zz x test-on.7z


## Possible cause

There appears to be a limitation or regression in the way Engrampa and
lxqt-archiver They handle encrypted 7z files, especially when the header
is protected. In practice, the frontend isn't detecting or properly
handling the password prompt, or it can't interpret the encrypted file
structure to list its contents.