signify with -C

[jmccue]

I am having an issue with how to use signify(1) on all files in a Directory. Some files could be quite large and based upon my searches and manuals, this shows the issue:

1. To sign the files I do the following:

$ sha256 * > SHA256
$ signify -S -s my.sec -m SHA256

2. This is where the issue occurs:

$ signify -C -p my.pub -x SHA256.sig
signify: signature verification failed

3. But this works.

$ signify -V -p my.pub -m SHA256
Signature Verified

$ sha256 -c SHA256
lots of OKs

Is there something I am missing in step 2 ? Or are we suppose to use the method in step 3 ? Or is the issue with #1 ? Based upon what I read # 2 should work.

Thanks

[jmccue]

Well I figured out what to do, this is what I believe is needed.

Sign:

$ sha256 * > SHA256
signify -S -s my.sec -m SHA256
cat SHA256 >> SHA256.sig

Then this now works:

signify -C -p my.pub -x SHA256.sig

If I am wrong please let me know

[jggimi]

If you put your checksum list file into the same directory, you can get a failing checksum when you test it. Example:

$ mkdir /tmp/test && cd /tmp/test
$ touch a b c
$ sha256 * > SHA256
$ sha256 -C SHA256 *
(SHA256) SHA256: FAILED
(SHA256) a: OK
(SHA256) b: OK
(SHA256) c: OK

The checksum file is not static. It is changing contents after it is first tested as the files a b c are checksummed later.

[IdOp]

In that example, I'm thinking that

$ sha256 * > SHA256

will create a checklist file SHA256 containing entries for files a, b and c, but not for itself since it doesn't exist when the * is interpreted. The next command

$ sha256 -C SHA256 *

then tests each file referenced by * against the checklist file entries. At this point the * does pick up SHA256 --- because it now exists --- and this leads to an error as indicated in sha256(1) about the -C option:

Any specified file that is not listed in the checklist will generate an error.

[jmccue]

About SHA256 makes sense, so I just need to do this instead just in case. But I did not originally run into the issue since SHA256* did not exist:

sha256 * | egrep -v '\(SHA256\)|\(SHA256\.sig\)' > SHA256

"SHA256 -c SHA256" by itself will not work for me since I am trying to use signify(1) for file signing instead of gpg(1).

As things stand, I think I am all set to sign all files (and large files) in a specific directory without using having to use gpg(1), unless someone knows of a better "signify" method of signing files.

It is interesting how this seems to be done, one signs SHA256 instead of each file in the directory. This is different than what you would do using gpg(1) and this method generates just 1 "signed" file instead of multiple *.asc files.

Thanks

[jggimi]

Originally Posted by IdOp

In that example, I'm thinking that

$ sha256 * > SHA256

will create a checklist file SHA256 containing entries for files a, b and c, but not for itself since it doesn't exist when the * is interpreted.

But that isn't what happens. The checklist file will include a listing for the file "SHA256" with an incorrect (still changing) hash.

[IdOp]

Originally Posted by jggimi

But that isn't what happens. The checklist file will include a listing for the file "SHA256" with an incorrect (still changing) hash.

Well that is interesting. Of course I didn't have a recent OpenBSD system to check it on, so what I did was run under ksh

% ls * > output

and the output file only showed the a, b and c files initially present. So it seems to be a subtly different behaviour between the two ksh shells in question? I will try to investigate a little more later, and sorry for any confusion.

[IdOp]

Ok this is bizarre ...

I have OpenBSD 6.1 on my laptop. It's not the latest, but better for this purpose than ksh on Linux.

So I tried my first example,

% ls -1 * > output

and sure enough the output file shows, a, b, c and output. Just as jggimi indicated.

So then I tried it with sha256 instead of ls,

% sha256 * > sums

Now the output file "sums" only contained checksums for a, b and c, but not itself ! This is different from the ls example, and from what jggimi found. Very strange. Maybe something has changed between ver. 6.1 and the latest?

[jmccue]

Originally Posted by IdOp

Now the output file "sums" only contained checksums for a, b and c, but not itself ! This is different from the ls example, and from what jggimi found. Very strange. Maybe something has changed between ver. 6.1 and the latest?

On 6.9 this

sha256 * > SHA256

did not add an entry for SHA256 in the output file. I wonder if the output is saved in memory prior to creating SAH256.

[jggimi]

Hmmm. I see where things went off the rails. I can create the changing checksum file in my usual interactive shell, tcsh. But with ksh, the checksum file itself is not included in the list of files produced. It's a difference of shell interpretation with globbing and piped output.

[IdOp]

Ahh, good to have that mystery solved.

What I still don't understand is why the similar-seeming examples with ls and sha256 in 6.1 gave different behaviour. But that question is straying off-topic from jmccue's thread so I will leave it there.

[jmccue]

Originally Posted by jggimi

Hmmm. I see where things went off the rails. I can create the changing checksum file in my usual interactive shell, tcsh. But with ksh, the checksum file itself is not included in the list of files produced. It's a difference of shell interpretation with globbing and piped output.

Well, interesting, I thought it was odd on OpenBSD via ksh, it was not seeing SHA256.

On my other systems (work) I am also a tcsh user, but on OpenBSD I have been staying with base ksh.

Thanks, good to know