Hi Thomas, On Sun, 5 Nov 2023, at 14:19, Tomasz Buchert wrote: > On 01/08/23 17:15, Nikolaus Rath wrote: >> Using -x instead of -m when verifying gives "interesting" output: >> >> $ signify-openbsd -Vz -p s3ql-5.0.pub -x signed.gz >> untrusted comment: verify with s3ql-5.0.pub >> RWSKPEtoJRYfrolP1xcoVCAxdIGvBp+I600+z5r4Ckcknx45J4pGrYvhlrWn6WTtwom7mTyjT7epM/oQyhfn/UbuKTR7pjN+0g0= >> date=2023-08-01T16:10:04Z >> key=s3ql-5.0.sec >> algorithm=SHA512/256 >> blocksize=65536 >> >> 05b894ec8534324eda46e2c71b2e9cd8c3e6f89432d222d06949076bc5236998 >> K����e2~⏎ >> >> >> This terminates with exit code 0... but somehow I'm not convinced that >> signify did the right thing here. >> > > I checked that signify puts the FCOMMENT section (from RFC) with > the signature and a bunch of other things at the preamble of the > signed gz file. The comment ends just after what looks like SHA256, > which is then followed by the binary data. The binary data is > identical to the main compressed data of the original file. > > In fact, it seems that the verification of gz files actually just > passes through the whole file. The man page implies that: > > Verify a gzip pipeline: > $ ftp url | signify-openbsd -Vz -t arc | tar ztf - > > The behavior seems then intended, but maybe it's not documented enough?
Sorry, I don't quite follow. The behavior of printing binary garbage to stdout is intended? Best, -Niko
