STDIN behaviour change ( 2.2.44/2.4.5)

Dirk-Willem van Gulik via Gnupg-devel <[email protected]>
Newsgroups gmane.comp.encryption.gpg.devel
Message-ID <[email protected]>
L.S.

After an update to 2.4.5 - we’re seeing an odd behaviour change (not sure it is regression) - where GPG seems to wait for an EOF as opposed to the end of message.

E.g. in 2.2.4 (libgcrypt 1.11.0) the following works

	# Setup test
	 echo foo | gpg -a -e -r dirkx > test.asc

	# cmd 1
	cat test.asc | gpg -d

	# cmd 2
	(cat test.asc; sleep 100) | gpg -d

With the latter command ‘2’ returning the decrypted value (foo) right away  - not waiting for the ‘sleep 100’. 

With version 2.45 (libgcrypt 1.8.)  this does -not- happen; ‘1’ outputs it right away; but in ‘2’ — gpg waits for sleep to time out; and the EOF to trigger decryption.

Is this a known/intentional change ? Any flags to get the old behaviour ? Any suggestions for a worn around (short of processing the message).

Dw

Background:

The use case for this is our use in pipelines — for example for an ZFS encrypted remove volume we; have an .ssh/authorized_key file with 

	command="cat /.key; /sbin/zfs load-key -L prompt XXXXX c && zfs mount XXXXX && echo OK” ssh-XXXX

And from the remote end ; we then do 

	mkfifo $FIFO
	cat $FIFO |\
		ssh -F $PINPAD_CONFIG_SSH -i $SSHKEY -T $host |\
		$GPG --quiet --default-key $PINPAD_KEYID >> $FIFO

So we rely on GPG acting on end of message, not EOF. And we have a few more complex cases - were multiple GPG blocks are handled this way with a single GPG (which we like - as there is some hardware/physical pin-pad/chipcard magic in the loop).



_______________________________________________
Gnupg-devel mailing list
[email protected]
https://lists.gnupg.org/mailman/listinfo/gnupg-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.