> 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
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
> 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
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
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
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,
> 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
