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
