Verifying software package download integrity
Typically any downloaded software packages will be supplied with a checksum value (usually MD5 or SHA256) and you should check that this checksum is correct after upload to the cluster to verify the integrity of the uploaded files.
An example of checking the integrity of the Make RPM is shown below using the
md5sum
and sha256sum
commands:
[user@node004 [stanage] yumpackages]$ md5sum make-3.82-24.el7.x86_64.rpm
c678cfe499cd64bae54a09b43f600231 make-3.82-24.el7.x86_64.rpm
[user@node004 [stanage] yumpackages]$ sha256sum make-3.82-24.el7.x86_64.rpm
d4829aff887b450f0f3bd307f782e062d1067ca4f95fcad5511148679c14a668 make-3.82-24.el7.x86_64.rpm
At this stage if being thorough you should check that any vendor or package maintainer signatures on the downloaded binary packages are valid.
If the vendor or maintainer has supplied a tarball or similar with an associated signature file (typically
packagename.tar.gz.asc
or packagename.tar.gz.sig
) then you can use gpg to check if it is valid as
demonstrated below with the GNU Make project’s source tarball:
[user@node004 [stanage] make]$ gpg --verify make-4.3.tar.gz.sig make-4.3.tar.gz
gpg: Signature made Sun 19 Jan 2020 22:24:43 GMT using RSA key ID DB78137A
gpg: Good signature from "Paul D. Smith <paul@mad-scientist.net>"
gpg: aka "Paul D. Smith <psmith@gnu.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 6D4E EB02 AD83 4703 510B 1176 80CB 727A 20C7 9BB2
Subkey fingerprint: B250 8A90 102F 8AE3 B12A 0090 DEAC CAAE DB78 137A
The GNU Make project documentation shows Paul D. Smith as the project maintainer and navigating to this personal site, http://make.mad-scientist.net/switching-gpg-keys/, shows the matching primary key fingerprint as expected and you can proceed with installing from the package.
Warning
Because we have not set Paul’s public key as trusted and signed his public key with our own private key, GPG will warn you that while the package is signed with Paul’s key, his key is not trusted nor can it verify it was indeed Paul’s key in the first place.
As it is possible for anyone to generate a signing key with anyone’s name or email, you must verify the public key that signed the package is Paul’s e.g. by confirming with an alternate source such as his website which publishes the expected fingerprint.
In order for GPG to trust the signature, several further commands are needed to add the key to your key chain, mark it as trusted then sign it with your own private key to establish a chain of trust / confirm to GPG you trust the key and have verified that it was indeed generated by Paul.
As this has several steps and is required it is out of scope of this page.