7z should not reject a correct password in console mode in Linux or Windows

[GregoryTrzonkowski]

Preconditions:

SystemRescue 9.03 (x86_64), Linux kernel: 5.15.43-1-lts, p7zip Version 17.04 (locale-en_US.UTF-8, Utf16=on,HugeFiles=on,64 bits, 4 CPU x64), xfce4-terminal 1.0.4.

Steps

1. $ startx
2. Open xfce4-terminal.
3. $ 7z a testarchive.7z -p -mhe testfile.txt
4. Input password that includes alt+o (the two buttons pressed simultaneously), e.g. "kók".
5. Retype the same password.
6. Go to console mode (Alt+Ctrl+F2).
7. $ 7z e testarchive.7z
8. Type the password, e.g. "kók".

Actual result

Archive is not extracted. Password is rejected.

7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=en_US.UTF-8, Utf16=on,HugeFiles=on, 64 bits, 4 CPUs x64)

Scanning the drive for archives:
1 file, 223 bytes (1 KiB)

Extracting archive: testarchive.7z

Enter password (will not be echoed):
ERROR: testarchive.7z
Can not open encrypted archive. Wrong password?

ERRORS:
Header Error

Can't open as archive: 1
Files: 0
Size: 0
Compressed: 0

There is the same error while extracting the archive on Windows. There isn't any error and the archive is extracted successfully if command input in the xfce4-terminal.

Expected behaviour

The password should be accepted and archive extracted.

7-Zip [64] 17.04 : Copyright (c) 1999-2021 Igor Pavlov : 2017-08-28
p7zip Version 17.04 (locale=en_US.UTF-8, Utf16=on,HugeFiles=on, 64 bits, 4 CPUs x64)

Scanning the drive for archives:
1 file, 223 bytes (1 KiB)

Extracting archive: testarchive.7z

Enter password (will not be echoed):
Path = testarchive.7z
Type = 7z
Physical Size = 223
Headers Size = 207
Method = LZMA2:12 7zAES
Solid = -
Blocks = 1

Everything is Ok

Size: 10
Compressed: 223

[tansy]

Where did you create this archive? Was it same console or different, or even different machine/system (like windows)?

[GregoryTrzonkowski]

The archive was created in the xfce4-terminal and not console. The machine (and the system) was the same (the detailed information is listed in the precondition section).

[jinfeihan57]

What encoding format does xfce4-terminal use？

Can you try a password using only English letters?

[GregoryTrzonkowski]

How to check what encoding format does xfce4-terminal use? There is the default one is UTF-8 in Terminal -> Set Encoding. Besides, there isn't any character displayed in the command prompt after input of the combination alt and o (unless alt + n or alt +p preceeds it and the result is: :^[o)

There isn't the bug if a password is set by input of characters without combination of alt and o. In other words, passwords composed of English letters only seem not to be affected by the bug.

[tansy]

It must be something to do with character encoding but if you use same terminal to encode and decode then it should work. Have you tried -scc switch? In help it says -scc{UTF-8|WIN|DOS} : set charset for for console input/output. Here you have it "recommended" by author himself. It would be -sccutf-8, I guess.

[jinfeihan57]

It should be the encoding problem of the character. The password should be entered in the same encoding format when compressing and decompressing.

[GregoryTrzonkowski]

I think that the problem is that 7z archives don't seem portable to a user as if they could only be decrypted on a machine (and software) where they were created.

There are differences in input methods between console mode and terminal emulators. In that case, pressing alt+o results in:

• o input in command line the console mode,
• nothing input in command line the terminal emulator. Would it be possible for 7z to detect and warn user about alt being pressed on a keyboard when typing a password, perhaps?

[tansy]

I don't think this makes sense. Other alphabets users don't use right-alt and they have the same problem, so it's marginal case. What it could do is to warn user to check the compressed archive and display character encoding used to create password. Something like this:

$ 7z a -p a.7z a.txt

(...)

Enter password (will not be echoed):

Password created with XYZ character encoding.

Files read from disk: 1
Archive size: 146 bytes (1 KiB)
Everything is Ok

[jinfeihan57]

I don't think this makes sense. Other alphabets users don't use right-alt and they have the same problem, so it's marginal case. What it could do is to warn user to check the compressed archive and display character encoding used to create password. Something like this:

$ 7z a -p a.7z a.txt

(...)

Enter password (will not be echoed):

Password created with XYZ character encoding.

Files read from disk: 1
Archive size: 146 bytes (1 KiB)
Everything is Ok

I think this is a possible solution. But this will change the format of 7z, adding the encoded information of the password.

[jinfeihan57]

Almost every type of text has its own encoding format, and some texts may have multiple encoding formats. This is set by the Operating System. The best solution to this problem is to use English letters as passwords, or make sure your clients use the same encoding format as you.