Mailing List Archive

> 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@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?
>

On Sun, 28 Apr 2024 13:02, Bee said:

>>+ (https://dev.gnupg.org/T4154)
[...]
>>+ 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.

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. It is also part of all kind of bug reports.


Shalom-Salam,

Werner


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

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@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@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?


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

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.


Salam-Shalom,

Werner

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

> 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
<wk_at_gnupg.org_omcujl92@duck.com> 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

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

> 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
<jcb62281_at_gmail.com_omcujl92@duck.com> 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