OPNsense Forum
English Forums => Documentation and Translation => Topic started by: eponymous on January 28, 2021, 06:17:50 pm
-
Hi,
FIrstly thanks to the OPNsense team for actually setting up signing for their images! This is something we expect these days but yet sadly isn't always taken seriously - especially by another "popular" firewall which still refuses to implement any sort of signing!
I did have a question about the documentation however and forgive me if I've missed something as I come from using GPG mostly.
In the installation section it states:
The OpenSSL tool is used for file verification. 4 files are needed for verification:
The bzip compressed ISO file (<filename>.iso.bz2)
The SHA-256 checksum file (<filename>.sha256)
The signature file (<filename>.sig)
The openssl public key (<filename>.pub)
The commands we use are:
openssl base64 -d -in <filename>.sig -out /tmp/image.sig
openssl dgst -sha256 -verify <key>.pub -signature /tmp/image.sig <image>.img.bz2
So from what I gather, once we've converted the signature back from base64 into binary in the first line, we then (in the second line) do the following, all-in-one:
1. Take the .sig signature (the SHA256 hash of the .img.bz2 signed with OPNsense's private key) and verify its authenticity using the provided public key (which I'd probably pull from another source for extra security).
2. Calculate the SHA256 hash of the .img.bz2 and compare that to the hash we just verified.
If those steps are correct, am I right in assuming the .sha256 file is acutally redundant? In which case we could maybe update the docs to state that verification of integrity & authenticity can be done with the commands above and only three files (.sig, .pub and .img.bz2)
However, if you just want to verify the integrity and perhaps not the authenticity then you can just use the .sha256 file and .img.bz2 file.
Sorry if I sound pedantic - I'm really just trying to understand the steps myself :)
Keep up the good work,
Cheers.
-
Hi and welcome,
Small anecdote:
We took the heat one or two times times for not providing GPG signatures, because we went with OpenSSL verification. It has its drawbacks, especially the two commands instead of one, but we think not having to install a third party component makes sense and can actually expand signature verification to users who have no experience with GPG (or even do not know how to install it).
Also, the key used to sign is what we use for package mirror signing as well so we don't need a separate GPG key... :)
So, anyway, you are correct. The sha256 is provided for additional integrity checking. We used to have an md5 equivalent as well but already got rid of it for obvious reasons. It may make sense to drop the sha256 file in the not too distant future, although it's no work at all to create and bundle it.
Cheers,
Franco
-
Thanks for clarifying and keep up the good work!