[TC 11.58rc3] Leaking encrypted names via logfile

[white]

I enabled the log file for Total Commander and unpacked a file from a header-encrypted archive.

The log file shows this:

11-06-2026 19:27:53: Unpack: d:\test secret.7z\test secret\secret2\tcmd1157x32.exe -> d:\zzz\tcmd1157x32.exe

Header encryption is intended to protect the filenames and folder structure inside the archive, making them inaccessible until the correct password is provided. However, logging the internal file path exposes this sensitive information in an unencrypted form, without requiring the password.

[Horst.Epp]

Logfile is not enabled by default.
So no security risk.
If I enable a log It's for seeing what happened.
Would be contra-productive to hide information from me.

[Dalai]

Header encryption is intended to protect the filenames and folder structure inside the archive [...]

Yes, but logging is intended to show everything that happens. Logging without accurate information is useless.

[JOUBE]

Header encryption is intended to protect the filenames and folder structure inside the archive [...]

Yes, but logging is intended to show everything that happens. Logging without accurate information is useless.

Of course, that's exactly how it should be.

There's clearly an interest here in damaging TC and its professional structures, turning it into an Explorer clone and thus making it suitable only for hobby users. But TC is too valuable for that, with its structures and standards built up over decades.

See also this thread: 11.58 RC3: Disagree with degradation for header-encrypted archives

[KozakMak]

critical vulnerability

[Flint]

There's clearly an interest here in damaging TC and its professional structures, turning it into an Explorer clone and thus making it suitable only for hobby users.

I'm not a conspirologist, but my world, it's really starting to look like it!

If I turn logging on, I want to have logging on — how hard can it be!

[Horst.Epp]

critical vulnerability

No, it's not
Read what others think about.

[DimmY]

I completely agree with Flint's arguments.

[CrMaReLi]

I enabled the log file for Total Commander and unpacked a file from a header-encrypted archive.

Header encryption is intended to protect the filenames and folder structure inside the archive, making them inaccessible until the correct password is provided. However, logging the internal file path exposes this sensitive information in an unencrypted form, without requiring the password.

If you did part 1, then do part 2 - set up a path for your logs to point at a safe location (maybe a password protected encrypted veracrypt partition\container), or set up a script to autodelete them or to delete them with one button.
Or just set up opening archives in an external software via internal associations (that's what they are for too - to exetend TC functionality\security\comfort with an external software when dealing with certain files)

No offense, but this "bug" is totally on you. Sounds like "I disabled driver signing check in windows, installed unsigned driver and now have bluescreens from time to time"

[white]

Logging should respect security boundaries. In FTP log files, for example, passwords are masked.

Logging should not bypass security, it should follow it. Encrypted and password protected data is only accessible via the password. Making this data available without these protections should not happen without the users explicit permission by entering the password.

Logging the decrypted data is actually worse than if TC would be logging the password for decrypting the data. The data is directly provided without even needing the password.

BTW, when packing to an archive (encrypted or not), the log file only shows the archive name and nothing else. Example:

12-06-2026 23:44:10: Pack: d:\test.7z

[CrMaReLi]

Logging should respect security boundaries. In FTP log files, for example, passwords are masked.

Logging should not bypass security, it should follow it. Encrypted and password protected data is only accessible via the password. Making this data available without these protections should not happen without the users explicit permission by entering the password.

Logging the decrypted data is actually worse than if TC would be logging the password for decrypting the data. The data is directly provided without even needing the password.

Worded this way that's not a rule but an opinion.

Logging should do logging and the user should consider software abilities and limitations. When software abilities are not enough, they should use another software or pipe the output to it. Also, if security limitations are that strict, using closed-source software that hasn't gone through security auditing and some other procedures, without combining it with other measures and software (decribed earlier) is at best silly.
And also - just viewing a list of files doesn't produce any logs. When you preview or unpack them however - at that point data is already unencrypted and even loaded in RAM, temp files or another software (which might do logging and creating temp files of it's own)

From the point the user entered their password (twice btw), enabled logging and specifically left unpacking logging turned on without pointing a log file to a secure location and also turned on logging of all successful operations and on Windows of all things (even tweaked\debloated one) - they entered a territory of operating with an unencrypted data.
And all words about data being provided without a password are clever, but simply not true. The data has been unencrypted via entering password twice at that point.

The only thing that I might agree on is that even with disabling packing logs TC still logs folder creation when unpacking encrypted 7z files with encrypted headers. AKA if archive has folders in it, then during unpacking TC treats unpacking those folders as creating folders in the filesystem and logs it.

[Flint]

Logging should respect security boundaries. In FTP log files, for example, passwords are masked.

Logging should not bypass security, it should follow it. Encrypted and password protected data is only accessible via the password. Making this data available without these protections should not happen without the users explicit permission by entering the password.

Logging the decrypted data is actually worse than if TC would be logging the password for decrypting the data. The data is directly provided without even needing the password.

You don't even follow your own logic. FTP in this regard is exactly like header-encrypted archives: you cannot see anything until you provide the password, not even the names. But in log files all the file/dir names are stored. Absolutely the same as with encrypted archives: the password is not shown in the log, but the accessed data is. So why is it OK for FTP, but not OK for encrypted archives?


I think Christian should just add an option MakeWhiteHappy=1 which will completely disable all access and operation with all encrypted and password-protected data: archives, FTP, SSH, Bitlocker/VeraCrypt/etc. encrypted volumes. No access, no logs, no password request dialogs. Everything super-secure.

And the rest of us will just use what WE think is suitable for our own needs.

[Sir_SiLvA]

I think Christian should just add an option MakeWhiteHappy=1 which will completely disable all access and operation with all encrypted and password-protected data: archives, FTP, SSH, Bitlocker/VeraCrypt/etc. encrypted volumes. No access, no logs, no password request dialogs. Everything super-secure.

And the rest of us will just use what WE think is suitable for our own needs.

100% agree with Flint, sorry white but you are 100% wrong on this one!

[ghisler(Author)]

I have experimented with this and I can limit what is logged for header-encrypted archives:
When packing, I already only log the name of the archive, so I can do the same also when unpacking, for example change:
Unpack: c:\path\secret.7z\subdir\file.ext -> d:\target\subdir\file.ext
to just
Unpack: c:\path\secret.7z

Alternatively, I could change it to
Unpack: c:\path\secret.7z\? -> d:\target\subdir\file.ext
but that would leak "subdir" from the archive too.

What do you think is better?

FTP in this regard is exactly like header-encrypted archives

The intention is not exactly the same: Header-encrypted archives are meant to protect the names of files and folders inside, while the purpose of FTP is to transfer files. The file names are not sent encrypted to the server, so other server users can see them too.

[CrMaReLi]

When packing, I already only log the name of the archive, so I can do the same also when unpacking, for example change:
Unpack: c:\path\secret.7z\subdir\file.ext -> d:\target\subdir\file.ext
to just
Unpack: c:\path\secret.7z

Alternatively, I could change it to
Unpack: c:\path\secret.7z\? -> d:\target\subdir\file.ext
but that would leak "subdir" from the archive too.

What do you think is better?

If we are going this route, does also change the thing, that TC logs folders and subfolders creation during this?
I'm not asking or demanding, just wondering