STDIN behaviour change ( 2.2.44/2.4.5)

[Dirk-Willem van Gulik]

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