Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> Yes, this is a fundamental limitation of public-key cryptography: to decrypt a message or generate a signature, the private key must be available in cleartext. Some would say that that is the point. But NOT necessarily saved in clear text to a storage medium. Which is what > Some would say that that is the point. [And if not in clear text, then some mechanism such as 'gpg -d -passphrase...' must be employed ... and we're circular back to the point of this thread.] > If you are trying to have some semblance of security with an unattended application, have you considered using a smartcard or HSM to store the key? [Again, unattended has not been an element herein. (Which doesn't mean it is contraindicated.)] If trying to avoid cleartext storage, and the infrastructure overhead of key storage, inherently there is no tolerance for the overhead of a smartcard or usb stewardship. And there is certainly no tolerance, and probably no capacity, for the creation or maintenance of a customized PINENTRY_USER_DATA (to receive the parameter) as T4154 suggests. Elements such as 'gpg -c ...' exist, for reasonable reasons, or the effort to code and document things such as passphrases would not have been made in the first place. I can understand, coming from the premise of 'public-key cryptography', that the assumption and requirement of one's own public-key storage infrastructure be in place. But the presence of 'passphrase' and 'gpg -c' notes that 'gpg' doesn't exist -only- -within- a public-key storage infrastructure. And thank all for having so. [This all matters because of the well deserved trust attached to 'gpg', its coding, its auditing, and every other good thing making it the world's 'go to' for this stuff - including passphrase use. It's a well known and trusted hammer, and everything herein IS a nail. Inherently, one wants to stay within the facilities it provides (like passphrases), rather than customize surroundings to be maintained that break those predicates.] Within the subject of this thread: "Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?" I simply provided one solution for later readers and web searchers. [Avoiding everyone easily visible command line and scripted storage of passphrase, and minimal time of visibility to sensitive data within a processes superuser-only visible environment variable storage. tmpfs being a memdisk and duration so short as to be unlikely to be swapped to physical medium.] If it is not entirely satisfactory, most certainly alternative passphrase examples would be most appreciated. And noted that appending an alternative workaround to the given patch provided therein at https://dev.gnupg.org/T4154 would be useful to web searchers. On Mon, Apr 29, 2024 at 8:14 PM Jacob Bachmeyer wrote: > > Bee via Gnupg-users wrote: > >> Its is called "USER DATA" for a reason - you have to decide what to do > >> with it. > >> > > > > But a novel pinentry must be created to receive the data. Again, this > > is circular. > > > > > >> If your really really want a passphrase, what about passing > >> the filename of a file holding the passphrase. > >> > > > > AGAIN, this requires clear text storage trying to be avoided in the > > first place, or ... decrypting the encrypted file on the fly ... which > > requires a passphrase to be passed ... and we're circular again. > > > > Yes, this is a fundamental limitation of public-key cryptography: to > decrypt a message or generate a signature, the private key must be > available in cleartext. Some would say that that is the point. > > If you are trying to have some semblance of security with an unattended > application, have you considered using a smartcard or HSM to store the key? > > > -- Jacob ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> Its is called "USER DATA" for a reason - you have to decide what to do > with it. But a novel pinentry must be created to receive the data. Again, this is circular. > If your really really want a passphrase, what about passing > the filename of a file holding the passphrase. AGAIN, this requires clear text storage trying to be avoided in the first place, or ... decrypting the encrypted file on the fly ... which requires a passphrase to be passed ... and we're circular again. > Or a socket or some > another secure IPC mechanism locator. Or ... 3 lines of script in the example you seem to be ignoring? mkfifo myfifo secret="passphrase" echo $secret > myfifo & unset secret echo "secret stuff" | gpg -c ... -fd 3 3< myfifo > For unattended use Unattended has not been mentioned. > For unattended use the only reason for a passphrase - which protects the > private key There is no private key in any scenario listed here. The point has been to avoid key infrastructure overhead entirely. [Yes, the passphrase is the key, but that is irrelevant semantics for purposes here.] Again ... 'echo "secret stuff" | gpg -c ...' Again, posting an actual workaround to the bottom of https://dev.gnupg.org/T4154 would be very welcome, and websearch visible to those so looking. - and the providing of such an example was the only purpose in writing the message you responded to, first, today. Saying the expressly desired use (e.g. dev.gnupg) is inappropriate is specious and counter-productive. Clearly the use is intended, given the presence of the word 'passphrase', even within 'man gpg'. On Mon, Apr 29, 2024 at 7:44 AM Werner Koch wrote: > > On Mon, 29 Apr 2024 07:03, Bee said: > > > But that environment is not passed and used by pinentry - it has no > > knowledge of them. PINENTRY_USER_DATA may exist, but it has no > > knowledge as to how to interpret it. Ergo, some other mechanism must > > Its is called "USER DATA" for a reason - you have to decide what to do > with it. If your really really want a passphrase, what about passing > the filename of a file holding the passphrase. Or a socket or some > another secure IPC mechanism locator. > > For unattended use the only reason for a passphrase - which protects the > private key against local users - are stupid policy requirements you > have to follow. In all other cases, first come up with an attack tree > to show that a passphrase is of any use for your application. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
Again, specious.
> Simply don't use a passphrase if you need to resort to such a thing. On
> many systems you - and other users - can easily look at the
> environment.
But that environment is not passed and used by pinentry - it has no
knowledge of them. PINENTRY_USER_DATA may exist, but it has no
knowledge as to how to interpret it. Ergo, some other mechanism must
be used. Such as an environment variable. So that the passphrase is
not visible within the script or a command line listing of the process
table. And preferably not even stored anywhere, in plain text.
A script (containing a hardwired passphrase) may well remain in
existence for some time, even, as a service, forever. The passphrase
remaining visible - both script, and/or command line, for the
duration. The solution given, for example, leaves no passphrase
visible in script or command line - in plain text only for the minimal
number of script lines - assuming a nefarious user is even present for
those microseconds,
never mind a casual one, -AND- that they have superuser privileges to
even be able to examine foreign (to the userid) process variables.
While even casual users can view scripts and process tables [but not
foreign process' environment variables].
It is quite evident that passphrase use is intended by gpg design.
Search 'passphrase' within 'man gpg' and one cannot escape such a
conclusion. Particularly '-c'.
e.g. echo "Secret data to be encrypted" | gpg -c ...
Examples of on the fly script use without key overhead have been
requested [here (thread(s) earlier) and elsewhere], that do not involve keys or
hardwiring a passphrase - without answer. If you have such, please
post. If I missed it, apologies, please advise of links.
If passphrase use was not to be used, then all code and documentation
containing the word 'passphrase' would have been stripped from the
content long ago. That it hasn't been can only be taken to mean that
it is intended and desired functionality.
A working alternative algorithm posted to the end of
https://dev.gnupg.org/T4154 would be welcome, and websearch visible to
those so looking. As it stands, things are circular - the suggested
solution is a custom PINENTRY_USER_DATA, and ergo a customized gpg
environment crafted to receive it, but if that were in place or desired, the
requested and delivered enhancement wouldn't be needed. This is
circular.
A working alternative (key-free and clear text free) algorithm posted
to the end of
https://dev.gnupg.org/T4154 would be welcome, and websearch visible to
those so looking.
On Sun, Apr 28, 2024 at 12:53 PM B.S. wrote:
>
>
> > At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
> environment variable', there is a comment of "I don't see why we
> should add yet more clumsy passphrase workarounds to gpg. We already
> have PINENTRY_USER_DATA which can fulfill the same task."
>
> Of course, the reference here to PINENTRY_USER_DATA is specious. To
> incorporate the processing of such a customized PINENTRY_USER_DATA requires
> the coding of a corresponding pinentry executable to receive it.
>
> And if one has the capacity to code one's own unique pinentry executable ...
> they could code around the stated problem outside of using PINENTRY_USER_DATA
> in the first place.
>
> And the T4154 request would never have been made, in the first place.
>
>
> So, given the above, a solution towards:
>
> >+ (https://dev.gnupg.org/T4154)
> >+
> >+ So this patch adds a new form of passphrase-passing, using an environment
> >+ variable. In POSIX shell, this looks like (for example):
> >+
> >+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
> >+ --passphrase-env=mypass --decrypt < message.txt
> >+
>
> can be effected without resorting to PINENTRY_USER_DATA - so no need to code,
> customize, maintain, update per gpg upgrades, or apply patches to in-house
> self-solutions.
>
>
> > Can anyone give an example of doing so?
>
> > I am looking to effect the equivalent of ...
>
> > Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA
> > which can fulfill the same task' of gpg picking up its passphrase from an
> > environment variable?
>
>
> Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html
> ('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for a
> more detailed example script solution, but in brief for this thread:
>
>
> gs_myfifo="$(mktemp -ut fifo.XXX)"
> mkfifo -m 0600 "${gs_myfifo}"
>
> gs_mysecretpassphrase="KXhtctw4_zFfhRop"
>
> echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
> unset gs_mysecretpassphrase
>
> echo -e "Stuff to be encrypted." \
> | gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}"
>
> rm "${gs_myfifo}"
>
>
> Of course, 'gs_mysecretpassphrase="KXhtctw4_zFfhRop"' would be replaced with
> some other mechanism of acquiring the passphrase. Perhaps via something such
> as:
>
> export GPG_TERM="${TERM}"
> echo -e "GETPIN\nBYE\n" \
> |
Re: Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
environment variable', there is a comment of "I don't see why we
should add yet more clumsy passphrase workarounds to gpg. We already
have PINENTRY_USER_DATA which can fulfill the same task."
Of course, the reference here to PINENTRY_USER_DATA is specious. To
incorporate the processing of such a customized PINENTRY_USER_DATA requires
the coding of a corresponding pinentry executable to receive it.
And if one has the capacity to code one's own unique pinentry executable
... they could code around the stated problem outside of using
PINENTRY_USER_DATA in the first place.
And the T4154 request would never have been made, in the first place.
So, given the above, a solution towards:
>+ (https://dev.gnupg.org/T4154)
>+
>+ So this patch adds a new form of passphrase-passing, using an environment
>+ variable. In POSIX shell, this looks like (for example):
>+
>+ mypass="IUuKctdEhH8' gpg --batch --pinentry-mode=loopback \
>+ --passphrase-env=mypass --decrypt < message.txt
>+
can be effected without resorting to PINENTRY_USER_DATA - so no need to
code, customize, maintain, update per gpg upgrades, or apply patches to
in-house self-solutions.
> Can anyone give an example of doing so?
> I am looking to effect the equivalent of ...
> Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA
which can fulfill the same task' of gpg picking up its passphrase from an
environment variable?
Examine https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067030.html
('How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?') for
a more detailed example script solution, but in brief for this thread:
gs_myfifo="$(mktemp -ut fifo.XXX)"
mkfifo -m 0600 "${gs_myfifo}"
gs_mysecretpassphrase="KXhtctw4_zFfhRop"
echo -e "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
unset gs_mysecretpassphrase
echo -e "Stuff to be encrypted." \
| gpg --pinentry-mode loopback --passphrase-fd 3 -c 3< "${gs_myfifo}"
rm "${gs_myfifo}"
Of course, 'gs_mysecretpassphrase="KXhtctw4_zFfhRop"' would be replaced
with some other mechanism of acquiring the passphrase. Perhaps via
something such as:
export GPG_TERM="${TERM}"
echo -e "GETPIN\nBYE\n" \
| pinentry --ttyname "${GPG_TTY}" \
| sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //"
On Thu, Mar 21, 2024 at 7:45 PM B.S. wrote:
> At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an
> environment variable', there is a comment of "I don't see why we
> should add yet more clumsy passphrase workarounds to gpg. We already
> have PINENTRY_USER_DATA which can fulfill the same task."
>
> Can anyone give an example of doing so?
>
> I am looking to effect the equivalent of:
> '@rem Get passhrase into (env.) var. programmatically (in your
> favourite manner)'
> 'set /p myenvpassphrase="Enter symmetric keyphrase to use:"
> 'echo "Secret data" | gpg.exe -c --envpassphrase myenvpassphrase >
> secretdata.gpg'
> - thereby avoiding storing any passphrase (even temporarily) on a
> storage medium, nor have it visible as the command line (via tasklist
> or ps).
> - in this case, the 'secret data' is actually confidential
> information, piped from elsewhere, on the fly.
>
> Of course, the '-envpassphrase' option doesn't exist in gpg currently,
> but the comment at the above link indicates that there is another way
> to effect the same intent.
>
> Can anyone give an example of so doing?
>
> A current means of effecting the same is, of course, '--passphase-fd
> 3", for something like:
> 'echo "Secret data" | gpg.exe -c --passphrase-fd 3 3< echo %PASSWORD%
> > secretdata.gpg'
> - except I have no idea [in (Win 10) DOS, not powershell, cmd] how to
> get anything into file descriptor 3.
> = let alone get an echo into fd 3 (without actually landing on a
> filesystem, even temporarily).
>
> Of course:
> 'echo "Secret data" | gpg.exe -c --passphrase > secretdata.gpg'
> - doesn't work, as stdin can't be 'in two places at once', both
> passphrase input, and data input.
> = Remember, "Secret data" isn't on disk, either - it's being piped in, too.
>
> Has anyone got a link to a working example of '3<' or
> 'PINENTRY_USER_DATA which can fulfill the same task' of gpg picking up
> its passphrase from an environment variable?
>
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
In the mean time, you could put something along the lines of:
{CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
listing: Forbidden - ignored$" or something, to keep that output out
of your stderr stream.
If something else unexpected displays, you'll get more issues, but
then you probably want to know if / when / should that happen.
If you add --quiet now, even when the change below happens later, your
script above won't need to change again.
On Fri, Apr 5, 2024 at 5:01 AM Werner Koch via Gnupg-users
wrote:
>
> Hi!
>
> > gpg: problem with fast path key listing: Forbidden - ignored
>
> I'll suppress that message in --quiet mode for the next release.
>
> ...
On Fri, Apr 5, 2024 at 11:24 AM Mike S wrote:
>
> Hello,
>
> is there a way to (re-)enable password storage and retrieval via secret
> service under KDE?
>
> The allow_external_password_cache option was disabled in this ticket:
> https://dev.gnupg.org/rPefb6de7fb2c15c1e31349b80fa7c8c1d4694c6cf
>
> But for me it would be useful to override this setting, I'm not using KWallet
> as my secret-service (I'm using KeePassXC), and are not affected by the
> possible deadlock.
> I thought about somehow changing the XDG_SESSION_DESKTOP env variable that
> pinentry-gtk-2 sees, but I don't think I can do that (because gpg-agent is
> launching pinentry?)
>
>
> Currently I downgraded the pinentry version.
> My problem is, that I sign my git commits and now I have to write my
> passphrase every time I commit.
> (With version 1.2.1-3 it takes the passphrase out of my KeePass database)
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?
=
Prologue:
Re-reading
https://web.archive.org/web/20171225062127id_/http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/redirection.mspx?mfr=true
, I now notice '<& Reads the input from one handle and writes it to
the output of another handle.' (Read from one, write to another.)
So 'echo %passphrase% <&3' would seem to input from stdin and output it to fd 3.
- I can’t think how to test this (under %COMSPEC%), though, and under
everything else it doesn’t matter. [If it doesn’t work there, there
are workarounds.]
- Under %COMSPEC%, file descriptors being broken – as below.
=
Answer / Solution: How can I 'echo' into fd 3 to be able to use it on
a gpg cmd line?
Summary:
- [outside of %COMSPEC%], short answer: mkfifo myfifo; echo
%passphrase% > myfifo & ; echo data | gpg ... 3< myfifo; unset
passphrase ; rm myfifo.
- [inside of %COMSPEC%], short answer: you can’t (*). %COMSPEC% file
descriptors are broken. See thread ending at
https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067020.html
- cygwin64 is gnupg unsupported, and cygwin32 is deprecated. See
https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067014.html
for why.
- even GnuWin (https://sourceforge.net/projects/gnuwin32/)
[https://getgnuwin32.sourceforge.net/] is of no help, the root cause
being %COMPEC%, everything run therein remains broken (in this regard)
– at least in terms of pipelining file descriptors outside of 0, 1, 2
== ‘stdin, out, err’. So, for example, 3, 4, 5, 6, and beyond ==
‘stdwarn, verb, debug, info’ [per
https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_redirection]
- use wsl, instead. [https://learn.microsoft.com/en-us/windows/wsl/install]
(*) Afterward:
- Werner kindly appended to the
https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067020.html
thread above, at
https://lists.gnupg.org/pipermail/gnupg-users/2024-March/067021.html,
indicating that a workaround for this %COMSPEC% issue will be included
in gnu2.6 – with the addition of a ‘--disable-fd-translation’ optional
parameter.
(Proof of Concept) Goal (Reminder):
- echo secret data | gpg –pinentry-mode loopback –passphrase-fd 3 -c
3< $(echo %passphrase%) ; unset passphrase
[i.e. without any unencrypted data landing within your filesystems,
pipe your sensitive data directly into gpg, towards direct secure
storage. e.g. (web) BitWarden backup towards secure (local) storage
should BitWarden servers ever become incommunicado (e.g. broken wi-fi
or internet provider). BitWarden phones home before unlocking – if it
can’t get there, you’re S.O.L.
- Nevermind the duplicate functionality of gpg vs Bitwarden, this is a
backup, and Bitwarden offers turnkey cross-machine consistency out of
the gate.
- - But thank all that is holy for what GnuPG was, is, and will be.
You want to have both applications to hand.
Proof of Concept example script solutions:
=
gpggetpin-wsl.cmd:
-
@rem #! %COMSPEC%
@echo off
set "GOTPASSPHRASE="
for /f "delims=" %%p in ('wsl /mnt/c/bin/gpggetpin.bash') do set
"GOTPASSPHRASE=%%p"
set /p "scratch=%GOTPASSPHRASE%" < nul:
set “ GOTPASSPHRASE=”
=
gpggetpin.bash:
-
#! /usr/bin/env bash
# gpggetpin.bash:
# SHORT VERSION:
# GPG_TTY=$(tty) ; printf "GETPIN\n" | pinentry -T "${GPG_TTY}" | sed
-e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //"
bash -n "${0}" || true
shellcheck -W 0 -Calways "${0}" || true
# printf "getpin\n" | pinentry -g -T "$(tty)"# - NOT HAPPY!
declare -g GPG_TERM ; GPG_TERM="${TERM}" ; export GPG_TERM
declare -g GPG_TTY ; GPG_TTY="$(tty)" ; export GPG_TTY
declare -g gs_passphrase="-1"
declare -gi gi_0=-1
gs_passphrase=\
"$( \
printf "SETDESC My description\nSETPROMPT My prompt\nSETTITLE My
window title, iif there is a window\nGETPIN\nBYE\n" \
| pinentry --debug --ttyname "${GPG_TTY}" --ttytype "${GPG_TERM}"
--lc-ctype "en_ca.UTF-8" --lc-messages "en_ca.UTF-8" \
| sed -e "s/^OK.*$//" -e "/^[[:space:]]*$/d" -e "s/^D //" \
)"
gi_0="${?}"
# USELESS - too many progs (retcodes) between source and end.
if false ; then
{
(( ! gi_0 )) && { printf "\n:: passphrase retrieval failed (%d),
exiting.\n\n" "${gi_0}" ; exit "${gi_0}" ; }
} ; fi
case "${gs_passphrase}" in
( "-1" );&
( "" );&
( "ERR 83886179 Operation cancelled " )
# printf ":: no valid password retrieved (%d)[%d]. Exiting.\n\n"
"${gi_0}" "${#gs_passphrase}"
exit "${gi_0}"
;;
(*);;
esac
# printf ":: passphrase retrieved (%d)[%d].\n\n" "${gi_0}" "${#gs_passphrase}"
# printf "\n|%s|\n\n" "${gs_passphrase}"
printf "%s" "${gs_passphrase}"
unset gs_passphrase
=
gpgtest-wsl.cmd:
-
@rem #! %COMSPEC%
@echo off
wsl /mnt/c/bin/gpgtest.bash
=
gpgtest.bash:
-
#! /usr/bin/env bash
printf "\n"
set -vx
declare -g gs_mysecretpassphrase="KXhtctw4_zFfhRop" # More usually
acquired somehow else.
declare -g gs_myfifo="$(mktemp -ut fifo.XXX)"
mkfifo -m 0600 "${gs_myfifo}"
printf "%s" "${gs_mysecretpassphrase}" > "${gs_myfifo}" &
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
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 0x0004 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 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 0x0003 > > 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
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
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 0x0004 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 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 0x0003 > > 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
Re: ''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
> 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 0x0003 > > 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 wrote: > > On Sat, 23 Mar 2024 21:17, Bee said: > > > Is 'gpg: failed to translate osfhandle 0x0003' known / expected? > > Don't mix Cygwin and plain Windows programs. On Sat, Mar 23, 2024 at 9:17 PM B.S. 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 0x0003 > > - > > > Is 'gpg: failed to translate osfhandle 0x0003' known / expected? > > Is there a workaround? > - same result for fd 8 and above. e.g. gpg: failed to translate > osfhandle 0x000b > > > 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
Re: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout?
On Mon, Mar 18, 2024 at 9:58 AM Werner Koch via Gnupg-users
wrote:
>
> On Sat, 16 Mar 2024 21:26, B.S. said:
> > ... (Windows 10) [DOS] cmd ... [*NOT* powershell]
> > ... cygwin gpg ...
>
> [Do not use a Cygwin build of gpg - this is not supported. Use a
> standard build for WIndows.]
Thanks kindly. Found https://dev.gnupg.org/T4059 {Jul 8 2018} from
Werner, to explain the point:
> Note that Cygwin is not a supported platform. Seems that the exec functions
> don't work on this 64 bit variant.
and
> ... it seems that GnuPG can be used on 32 bit Cygwin
Very Good to know.
And ... 32-bit cygwin is no longer maintained / supported, as of
version 3.3.6, around 11/11/2022, per
https://cygwin.com/pipermail/cygwin-announce/2022-November/010810.html
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users
''gpg: failed to translate osfhandle 0x00000003' known|expected? -fd 4-7 doesn't.
>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 0x0003 - Is 'gpg: failed to translate osfhandle 0x0003' known / expected? Is there a workaround? - same result for fd 8 and above. e.g. gpg: failed to translate osfhandle 0x000b 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
Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?
At https://dev.gnupg.org/T4154 , 'allow setting passphrase from an environment variable', there is a comment of "I don't see why we should add yet more clumsy passphrase workarounds to gpg. We already have PINENTRY_USER_DATA which can fulfill the same task." Can anyone give an example of doing so? I am looking to effect the equivalent of: '@rem Get passhrase into (env.) var. programmatically (in your favourite manner)' 'set /p myenvpassphrase="Enter symmetric keyphrase to use:" 'echo "Secret data" | gpg.exe -c --envpassphrase myenvpassphrase > secretdata.gpg' - thereby avoiding storing any passphrase (even temporarily) on a storage medium, nor have it visible as the command line (via tasklist or ps). - in this case, the 'secret data' is actually confidential information, piped from elsewhere, on the fly. Of course, the '-envpassphrase' option doesn't exist in gpg currently, but the comment at the above link indicates that there is another way to effect the same intent. Can anyone give an example of so doing? A current means of effecting the same is, of course, '--passphase-fd 3", for something like: 'echo "Secret data" | gpg.exe -c --passphrase-fd 3 3< echo %PASSWORD% > secretdata.gpg' - except I have no idea [in (Win 10) DOS, not powershell, cmd] how to get anything into file descriptor 3. = let alone get an echo into fd 3 (without actually landing on a filesystem, even temporarily). Of course: 'echo "Secret data" | gpg.exe -c --passphrase > secretdata.gpg' - doesn't work, as stdin can't be 'in two places at once', both passphrase input, and data input. = Remember, "Secret data" isn't on disk, either - it's being piped in, too. Has anyone got a link to a working example of '3<' or 'PINENTRY_USER_DATA which can fulfill the same task' of gpg picking up its passphrase from an environment variable? ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout?
> However if you known the passphrase, you can pass it to gpg directly using > --passphrase-file and --pinentry-mode=loopback. I figured, but am trying to avoid having the passphrase land on disk at all. > Due to the way a pipe works there is not much you can do here. Except (I would hope?) if gpg were to make sure nothing is written to stdout until after passphrase was completely acquired, before decrypting and writing the decrypt to sdtout, I don't expect less will have cleared the screen to that point. [Less waits to clear screen, etc., until after it receives something / anything at stdin. (?)] > You are using a Cygwin version of the standard shell here? No, standard DOS prompt (Win 10). Just that cygwin is along the path. (It's win jq, in this case, however.) [cygwin less.exe being quieter and more functional than dos' more.exe.] > make sure that jq.exe gets its EPIPE from the failed gpg.exe. (1) EPIPE? As in '2|' - that's a thing (in 'Win 10' dos)? (2) gpg has not failed here. I guess the issue is also gpg displaying prompt, also confusing less. I will have to try 'gpg.exe -d somefile.gpg < con: 2> nul: | jq.exe | less', or something like. Curious that '( gpg.exe -d somefile.gpg | jq.exe ) | less' displays sufficiently well - I'm guessing I'm just getting lucky with (sub-shell?) delays, giving things time to display. On Mon, Mar 18, 2024 at 9:55 AM Werner Koch wrote: > > On Sat, 16 Mar 2024 21:26, B.S. said: > > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > > ... cygwin gpg ... > > [Do not use a Cygwin build of gpg - this is not supported. Use a > standard build for WIndows.] > > > How can I have gpg pause to receive its passphrase, before it starts > > outputing decrypt to stdout? > > Due to the way a pipe works there is not much you can do here. Except > for having some kind buffering tool in between. Howeverm if you known > the passphrase, you can pass it to gpg directly using --passphrase-file > and --pinentry-mode=loopback. > > > So if gpg could finish getting its passphrase from 'readline' before > > opening stdout (that less then sees to clear the screen and open its > > The pipeline is constructed by the shell (cmd.exe) and file descriptors > are given to the programs. There is nothing any of the programs can do > here. In fact when using a pipeline in this way, the next program in > the line should be able to handle the output of the former which means > it will expect valid output. > > > So far: > > ( gpg.exe -d somefile.gpg | jq.exe ) | less > > You are using a Cygwin version of the standard shell here? In this case > make sure that jq.exe gets its EPIPE from the failed gpg.exe. > > You may consider to use gpgme-json as a higher level API to gpg. But of > course it does not work the usual way in a pipe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
How can I 'echo' into fd 3 to be able to use it on a gpg cmd line?
... (Windows 10) [DOS] cmd ... [*NOT* powershell] ... cygwin gpg ... How can I 'echo' into fd 3 to be able to use it on a gpg cmd line? e.g. 'echo "Secret data" | gpg.exe -c -passphrase-fd 3 3< echo %PASSWORD%' [Ignore the need, or not, for --batch and/or --pinentry-mode loopback, I can wrestle with those separately.] (I am trying to avoid the passphrase from appearing in cleartext within tasklists, etc.) I am working on a BitWarden(-cli) backup script. So the 'echo "Secret data"' above is actually something like: bitwarden-cli --export json | gpg -c ... >...bitwarden_backup.json.pgp - the hangup seems to be how to echo into 3< to be able to use it as input, for ' -passphrase-fd 3'. [Or 7< echo %PASSWORD%, for that matter - it seems powershell uses 3-6 for stdwarn|verbose|debug|info, and probably best to avoid potential future conflicts.] ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: How can I have gpg pause to receive its passphrase, before it starts outputing decrypt to stdout?
> However if you known the passphrase, you can pass it to gpg directly using > --passphrase-file and --pinentry-mode=loopback. I figured, but am trying to avoid having the passphrase land on disk at all. > Due to the way a pipe works there is not much you can do here. Except (I would hope?) if gpg were to make sure nothing is written to stdout until after passphrase was completely acquired, before decrypting and writing the decrypt to sdtout, I don't expect less will have cleared the screen to that point. [Less waits to clear screen, etc., until after it receives something / anything at stdin, IIRC.] > You are using a Cygwin version of the standard shell here? No, standard DOS prompt (Win 10). Just that cygwin is along the path. (It's win jq, in this case, however.) [cygwin less.exe being quieter and more functional than dos' more.exe.] > make sure that jq.exe gets its EPIPE from the failed gpg.exe. (1) EPIPE? As in '2|' - that's a thing (in 'Win 10' dos)? (2) gpg has not failed here. I guess the issue is also gpg displaying prompt, also confusing less. I will have to try 'gpg.exe -d somefile.gpg < con: 2> nul: | jq.exe | less', or something like. Curious that '( gpg.exe -d somefile.gpg | jq.exe ) | less' displays sufficiently well - I'm guessing I'm just getting lucky with (sub-shell?) delays, giving things time to display. On Mon, Mar 18, 2024 at 9:58 AM Werner Koch via Gnupg-users wrote: > > On Sat, 16 Mar 2024 21:26, B.S. said: > > ... (Windows 10) [DOS] cmd ... [*NOT* powershell] > > ... cygwin gpg ... > > [Do not use a Cygwin build of gpg - this is not supported. Use a > standard build for WIndows.] > > > How can I have gpg pause to receive its passphrase, before it starts > > outputing decrypt to stdout? > > Due to the way a pipe works there is not much you can do here. Except > for having some kind buffering tool in between. Howeverm if you known > the passphrase, you can pass it to gpg directly using --passphrase-file > and --pinentry-mode=loopback. > > > So if gpg could finish getting its passphrase from 'readline' before > > opening stdout (that less then sees to clear the screen and open its > > The pipeline is constructed by the shell (cmd.exe) and file descriptors > are given to the programs. There is nothing any of the programs can do > here. In fact when using a pipeline in this way, the next program in > the line should be able to handle the output of the former which means > it will expect valid output. > > > So far: > > ( gpg.exe -d somefile.gpg | jq.exe ) | less > > You are using a Cygwin version of the standard shell here? In this case > make sure that jq.exe gets its EPIPE from the failed gpg.exe. > > You may consider to use gpgme-json as a higher level API to gpg. But of > course it does not work the usual way in a pipe. ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
