Dear Maintainer,

I believe this should work, but it does not:

$ signify-openbsd -Sz -s signify/s3ql-5.0.sec -m dist/s3ql-5.1.0.tar.gz -x out.gz
$ signify-openbsd -Vz -m out.gz -p signify-s3ql-5.0.pub
signify-openbsd: can't open out.gz.sig for reading: No such file or directory


Am I holding this wrong?

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.

Best,
-Nikolaus

Hey Nikolaus,

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?

Cheers,
Tomasz

Hi Thomas,

Sorry, I don't quite follow. The behavior of printing binary garbage to stdout is intended?


Best,
-Niko

Hey,

the "binary garbage" you see is actually the exact contents of the gz file for which you verify. See:

[ ~/test ] $ cat out.gz | signify-openbsd -Vz -p ~/.ssh/signify.pub | cat > x
[ ~/test ] $ diff x out.gz

(i.e., out.gz and the output of signify are exactly the same)

This allows to use it cleanly in the shell pipelines as is shown in the manpage.

I think the request in this bug could be to have an option to verify the
signify-signed gz file WITHOUT printing out the gz file to stdout?

Does it make sense?

Tomasz

Yes. Wow, it never would have occured to me that this is the intended effect. You're right, this matches the example in the manpage but to me it's wholly unexpected given the description of the option:

     -z           Sign and verify gzip(1) archives, where the signing data is embedded in the gzip(1)
                   header.

(doesn't say anything about printing to stdout)

Best,
-Niko