Example of 'PINENTRY_USER_DATA which can fulfill the' (envpassphrase) 'task'?

[omcujl92 at duck.com]

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. <bs27975 at gmail.com> 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" \
> | 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. <bs27975 at gmail.com> 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?