Page MenuHome GnuPG

GnuPG: 8Bit filenames can no longer be provided on the command line
Open, WishlistPublic

Description

This is similar to T5226 and a regression from the unicode changes / using utf-8 internally. Related discussion to this is: https://wald.intevation.org/forum/message.php?msg_id=7685&group_id=11

The only way to encrypt files with an 8 bit character seems to be to pipe it through the command.
I would look forward to an example that explains how you could still use the filename arguments on Windows using CMD or PowerShell. I can't find a way. Even when you use CHCP 65001 it only changes the output / display but not the input of arguments.

To reproduce just create a file täst.txt and try to encrypt it on the command line.

Maybe for 2.3 we could try to solve this by adding a wmain?

Event Timeline

You can use --multifile for this. This reads the filenames from a descriptor or a file. One on the reasons to implement Unicode handling at most places was a request to allow using --multifile as a workaound for the command line limitation..

And in fact it was never possible to use 8bit filenames on the command line. The result was not stable and led to non-compatible messages due to the use of native character set instead of proper utf-8. It depended on just too much things.
gpgme-tool or gpgme-json might be useful workaround.

werner claimed this task.

I mentioned it several times: It is not sufficient to use some wmain as long as we don't rework the entire spawn machinery in gnupg. libassuan and gpgme. Reading Unicode from the command line would be easy the other things are the real work.

But okay, if you want that we can do that but then don't expect 2.3 before summer.

aheinecke claimed this task.

I have to leave this as open as this describes a clear issue users expirience in our software. I assign it to me to keep an eye on the issue. Werner and me discussed this issue at length verbally and there won't be a quick fix for the stable branch but we will address this some time in the future, but then not only for 8bit but for full unicode.

The problem here is that we are going in the direction of full unicode but are not there yet and don't want to add hacks to support 8bit in the meantime. Because any hack we would add now would be stable api for us und might break with proper solutions in the future.

aheinecke triaged this task as Wishlist priority.Feb 4 2021, 12:46 PM