Mailing List Archive

On Sat, 23 Mar 2024 21:17, Bee said:

> Is 'gpg: failed to translate osfhandle 0x00000003' known / expected?

Don't mix Cygwin and plain Windows programs.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

> Don't mix Cygwin and plain Windows programs.

cygwin has nothing to do with this thread - there is no element of
cygwin within the quoted code or results.

As said, this is pure GnuPG from
> From https://gnupg.org/download/index.html:
> Windows ...
> download sig Simple installer for the current GnuPG <-- https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.5_20240307.exe

> C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt
> gpg: failed to translate osfhandle 0x00000003
>
> C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 4 -c 4< HelloWorld.txt
> - brought up a pinentry-qt dialogue. i.e. didn't read from fd 4.

Is there a workaround?

Tried '--pinentry-mode loopback', as well, to no joy.

Using fd 4, '--pinentry-mode loopback' returned:
gpg: error creating passphrase: Invalid passphrase
gpg: symmetric encryption of '[stdin]' failed: Invalid passphrase


On Mon, Mar 25, 2024 at 5:49?AM Werner Koch
<wk_at_gnupg.org_omcujl92@duck.com> wrote:
>
> On Sat, 23 Mar 2024 21:17, Bee said:
>
> > Is 'gpg: failed to translate osfhandle 0x00000003' known / expected?
>
> Don't mix Cygwin and plain Windows programs.


On Sat, Mar 23, 2024 at 9:17?PM B.S. <bs27975@gmail.com> wrote:
>
> From https://gnupg.org/download/index.html:
> Windows ...
> download sig Simple installer for the current GnuPG <--
> https://gnupg.org/ftp/gcrypt/binary/gnupg-w32-2.4.5_20240307.exe
>
> -----
>
> C:\Program Files (x86)\GnuPG\bin>ver
>
> Microsoft Windows [Version 10.0.19045.4123]
>
> C:\Program Files (x86)\GnuPG\bin>.\gpg.exe --version
> gpg (GnuPG) 2.4.5
> libgcrypt 1.10.3
> Copyright (C) 2024 g10 Code GmbH
> ...
>
> C:\Program Files (x86)\GnuPG\bin>echo Hello World > HelloWorld.txt
>
> C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe
> --passphrase-fd 3 -c 3< HelloWorld.txt
>
> gpg: failed to translate osfhandle 0x00000003
>
> -----
>
>
> Is 'gpg: failed to translate osfhandle 0x00000003' known / expected?
>
> Is there a workaround?
> - same result for fd 8 and above. e.g. gpg: failed to translate
> osfhandle 0x0000000b
>
>
> Curiously:
> C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe
> --passphrase-fd 4 -c 4< HelloWorld.txt
>
> - brought up a pinentry-qt dialogue. i.e. didn't read from fd 4.
> - same for fd 5, 6, and 7.
>
> Is there a workaround?


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, 25 Mar 2024 08:33, Bee said:

> C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt
>> gpg: failed to translate osfhandle 0x00000003

gpg takes system handles and not libc file descriptors. File
descriptors 0, 1, and 2 are handled by Windows in a different. All
other depend on which ABI you work. cmd.exe seems to expect file
descriptors which is good for scripting but gpg is rarely used in such a
scripting environment but usuallay directly executed by CreateProcess
and thus expects HANDLE values and not file descriptors.

See gnupg/common/sysutils.c:translate_sys2libc_fd

Actually it would be possible to provide an option to disable this
translation and instead use libc file descriptors (with all the fun if
different runtimes are used) but in more than 20 years we have not seen
such a demand.


Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Thank you.

I don't follow all of that, such as deep diving into
gnupg/common/sysutils.c:translate_sys2libc_fd , but I do get the
answer is: Unsupported (at least at this time).

Could you make whatever notation at dev.gnupg.org is appropriate, please?
Summary: --passphrase-fd #, where # >= 3, fails under Windows / DOS
%COMSPEC% == unsupported (at this time).

So that, with that and this list, web searchers looking to figure out
why the described '--passphrase-fd #' isn't working for them, stop
chasing their tails?
[.i.e. it's not user error, it's a Windows (DOS) issue not yet worked around].

-----

It is curious that fd 4 produced the different result of triggering a
graphical pinentry. I presume the file open failed and it fell back to
that mechanism.

And, interesting that under wsl:
'cat HelloWorld.txt | gpg.exe --pinentry-mode loopback --passphrase-fd
4 -c 4< HelloWorld.txt' returned the expected consistent result for
fd 3.
[with and without --pinentry-mode loopback]
> gpg: failed to translate osfhandle 0x00000004

Interesting in that:
(1) A call to an .exe file ran 'properly' (under wsl) at all. [Who
knew!] (Once I did, seemed worth a try, here.)
(2) The surrounding os file redirection services (between cmd.exe and
wsl.exe) are inconsistent - wsl.exe side behaviour better operating in
the traditional and expected manner, than cmd.exe.

> lsb_release -a ; uname -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
Linux host 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5
21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

On Mon, Mar 25, 2024 at 12:21?PM Werner Koch
<wk_at_gnupg.org_omcujl92@duck.com> wrote:
>
> On Mon, 25 Mar 2024 08:33, Bee said:
>
> > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt
> >> gpg: failed to translate osfhandle 0x00000003
>
> gpg takes system handles and not libc file descriptors. File
> descriptors 0, 1, and 2 are handled by Windows in a different. All
> other depend on which ABI you work. cmd.exe seems to expect file
> descriptors which is good for scripting but gpg is rarely used in such a
> scripting environment but usuallay directly executed by CreateProcess
> and thus expects HANDLE values and not file descriptors.
>
> See gnupg/common/sysutils.c:translate_sys2libc_fd
>
> Actually it would be possible to provide an option to disable this
> translation and instead use libc file descriptors (with all the fun if
> different runtimes are used) but in more than 20 years we have not seen
> such a demand.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service. - A. Einstein


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Thank you.

I don't follow all of that, such as deep diving into
gnupg/common/sysutils.c:translate_sys2libc_fd , but I do get the
answer is: Unsupported (at least at this time).

Could you make whatever notation at dev.gnupg.org is appropriate, please?
Summary: --passphrase-fd #, where # >= 3, fails under Windows / DOS
%COMSPEC% == unsupported (at this time).

So that, with that and this list, web searchers looking to figure out
why the described '--passphrase-fd #' isn't working for them, stop
chasing their tails?
[.i.e. it's not user error, it's a Windows (DOS) issue not yet worked around].

-----

It is curious that fd 4 produced the different result of triggering a
graphical pinentry. I presume the file open failed and it fell back to
that mechanism.

And, interesting that under wsl:
'cat HelloWorld.txt | gpg.exe --pinentry-mode loopback --passphrase-fd
4 -c 4< HelloWorld.txt' returned the expected consistent result for
fd 3.
[with and without --pinentry-mode loopback]
> gpg: failed to translate osfhandle 0x00000004

Interesting in that:
(1) A call to an .exe file ran 'properly' (under wsl) at all. [Who
knew!] (Once I did, seemed worth a try, here.)
(2) The surrounding os file redirection services (between cmd.exe and
wsl.exe) are inconsistent - wsl.exe side behaviour better operating in
the traditional and expected manner, than cmd.exe.

> lsb_release -a ; uname -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.3 LTS
Release: 22.04
Codename: jammy
Linux host 5.15.133.1-microsoft-standard-WSL2 #1 SMP Thu Oct 5
21:02:42 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux


On Mon, Mar 25, 2024 at 12:21?PM Werner Koch
<wk_at_gnupg.org_omcujl92@duck.com> wrote:
>
> On Mon, 25 Mar 2024 08:33, Bee said:
>
> > C:\Program Files (x86)\GnuPG\bin>type HelloWorld.txt | .\gpg.exe --passphrase-fd 3 -c 3< HelloWorld.txt
> >> gpg: failed to translate osfhandle 0x00000003
>
> gpg takes system handles and not libc file descriptors. File
> descriptors 0, 1, and 2 are handled by Windows in a different. All
> other depend on which ABI you work. cmd.exe seems to expect file
> descriptors which is good for scripting but gpg is rarely used in such a
> scripting environment but usuallay directly executed by CreateProcess
> and thus expects HANDLE values and not file descriptors.
>
> See gnupg/common/sysutils.c:translate_sys2libc_fd
>
> Actually it would be possible to provide an option to disable this
> translation and instead use libc file descriptors (with all the fun if
> different runtimes are used) but in more than 20 years we have not seen
> such a demand.
>
>
> Salam-Shalom,
>
> Werner
>
> --
> The pioneers of a warless world are the youth that
> refuse military service. - A. Einstein


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

On Mon, 25 Mar 2024 19:55, Bee said:

> Could you make whatever notation at dev.gnupg.org is appropriate, please?

https://dev.gnupg.org/T7060

Already implemented a new option but you need to wait for gnupg 2.6.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein