Hello everyone,

Was traveling for the last few days and while residing in a hotel, I suspect they had a web proxy in between all clients and the internet.
While in the hotel, did the usual slackpkg update followed with the upgrade-all.
Then noticed quite a few md5 errors on the downloaded packages...

Quick question:-
Days later how do I go about verifying all packages downloaded and installed haven't been messed around with by comparing to the packages on the main repository?

Thanks in advance.

Did you check whether you still have the packages you installed on disk? Slackpkg stores them under /var/cache/packages. You can check those against ones from a Slackware mirror.

I would do it by reinstalling suspect packages.

1 members found this post helpful.

The default /etc/slackpkg/slackpkg.conf has this set:
It checks the GPG signatures against the security@slackware.com public key you have earlier imported. The hotel doesn't have Patrick's private key to sign the messed around packages.

The md5 errors are possible if you downloaded from a mirror which was updating (or its update had been interrupted) and CHECKSUMS.md5 and the packages did not match at the moment.

2 members found this post helpful.

I would do the following:

1. Download the file CHECKSUMS.md5 for your version of Slackware
2. Download the file CHECKSUMS.md5.asc, also from your favorite mirror
3. Validate the file CHECKSUMS.md5 with the command: "gpg --verify CHECKSUMS.md5"
4. Once you can trust the big file CHECKSUMS.md5, make a copy and in that copy only keep the lines of the files that you want to test. You might also want to edit the paths to those files if you have stored them somewhere else.
5. Run the command "md5sum -c my_copy_of_CHECKSUMS.md5"

The following assumes that you since previously have stored the public GPG-KEY in your keyring. If you already haven't done so and don't trust your downloads, you will be able to find that file on old official installation media if you happen to have any such laying around. The man page of gpg describes how to add such a public key to your keyring.

regards Henrik

2 members found this post helpful.

Only if DELALL=off. The default is DELALL=on.

From slackpkg.conf.

2 members found this post helpful.

If you want to check which installed packages have a problem before taking any other action or because you didn't save the list of packages with md5sum error warnings, then do as @henca wrote first.

If you saved the list of files with md5sum error warnings, and you still want to go through those steps, it might save a bit of your time to skip step 4 and change the last command to
If what you're actually trying to do is most quickly make sure all upgraded packages are verified and installed correctly, then this set of steps probably takes the least amount of your time:

With the list of packages that showed those errors, do as @allend wrote and use slackpkg to try reinstalling each one individually.
ex. You can, but don't need to, write out the full packagename without its extension
ex. If many packages from a set showed md5sum error warning, it might save you more of your time to reinstall the whole set.

If the warnings are because your mirror was syncing while you were upgrading packages or had some other problem, you will have to wait until that's resolved to reinstall, or you could temporarily pick another mirror in /etc/slackpkg/mirrors that is up to date.

TheTKS

1 members found this post helpful.

In commands:

Change bash for your packages files.

2 members found this post helpful.

Thanks everyone.
My bad I did not print-screen as I was in a hurry to go into a meet.
Just to be sure, I've decided to download the repo reinstall the packages from scratch.

But OTOH, what mechanisms are in place to thwart a mirror being compromised OR having an mitm such as a packetlogic (nowadays sandvine) hijack the downloads?

Every package is signed by Patrick's private key, and the corresponding public key is downloaded from a different source, not from the repository itself. Even if the repository were compromised by rogue packages with corresponding md5sums, they couldn't be signed correctly. But this depends on users not switching off signature checking in slackpkg.

5 members found this post helpful.

Awesome info.

I just dug a bit deeper into this, having run into this before myself.

Slackpkg doesn't install packages when an MD5 check fails. An attempt is made to download a package multiple times. Each time a package check fails after download, the error is reported, but when it tries again and succeeds, its installed.

What that won't protect against is a downgrade attack: where a repo is MITM'd to an older state containing older known to be vulnerable packages (complete with their genuine signatures). To prevent that sort of thing Pat would have to start including an incremental sequence number in the signed CHECKSUMS.md5 that could be checked by update tools.

2 members found this post helpful.