Page MenuHome GnuPG
Create Task
Maniphest T5285

GnuPG: 8Bit filenames can no longer be provided on the command line
Closed, ResolvedPublic
Actions

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?

Related Objects

Event Timeline

aheinecke created this task.Feb 3 2021, 9:34 AM
• werner added a subscriber: • werner.EditedFeb 3 2021, 3:20 PM

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..

• werner added a comment.Feb 3 2021, 3:24 PM

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 closed this task as Wontfix.Feb 3 2021, 3:26 PM
• 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 reopened this task as Open.Feb 4 2021, 12:46 PM
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
bernhard added a subscriber: bernhard.EditedMay 21 2021, 4:16 PM

Could make --multifile work on windows 10, documenting the workaround here.

  • using cmd.exe
  • chcp shows 437
C:\Users\IEUser>echo hö >hö.txt

C:\Users\IEUser>chcp 65001
Aktive Codepage: 65001.

C:\Users\IEUser>echo hö.txt|gpg --encrypt -r bernhard+t2 --multifile

C:\Users\IEUser>echo hö.txt.gpg|gpg --decrypt --multifile
gpg: verschlüsselt mit 3072-Bit RSA Schlüssel, ID B6A53FC39D3B85F4, erzeugt 2021-05-21
      "bernhard+t2@intevation.de"

C:\Users\IEUser>chcp 437
Aktive Codepage: 437.

C:\Users\IEUser>type hö.txt
hö

not working cases

  • using cmd.exe
  • chcp shows 437
  • echo some text >hä.txt
  • gpg --encrypt -r bernhard hä.txt fails with
gpg: 'hΣ.txt' kann nicht geöffnet werden: Systemfehler ohne gesetzten Systemfehlercode
gpg: hΣ.txt: encryption failed: Systemfehler ohne gesetzten Systemfehlercode
  • echo hä.txt| gpg --encrypt -r bernhard --multifile also fails, but shows
gpg: 'hä.txt' kann nicht geöffnet werden: Systemfehler ohne gesetzten Systemfehlercode
gpg: encryption of 'hä.txt' failed: Systemfehler ohne gesetzten Systemfehlercode
• werner closed this task as Resolved.Jun 9 2021, 10:42 AM

Now also fixed for 2.2.28