> 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_omcuj...@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
