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

[omcujl92 at duck.com]

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