[SOLVED] I have run slackpkg update gpg instead of slackpkg update
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
afterwards and it completed the updates successfully.
Is running slackpkg update gpg by mistake going to cause a problem?
I run gpg update every time before update mainly because I use bash history and all the commands are in an && command line, including install-new. It hasn't hurt anything so far.
Is running slackpkg update gpg by mistake going to cause a problem?
No. Running 'slackpkg update gpg' simply checks your key file for the signatures, if not found, adds them; otherwise nothing is changed. If you look closely at the output of 'slackpkg update gpg' you will see the following after each signature is checked if nothing has changed.
I must be more careful with slackpkg in future though. I might not be so lucky next time.
slackpkg is fairly safe to use. The gotcha could be 'slackpkg clean-system' and third party packages, if they are not in the blacklist, they could be removed. The good thing is with the default settings in /etc/slackpkg/slackpkg.conf, you get a chance before committing with the selection screen dialog. True is for other options that will upgrade or install new slackware packages.
I use slackpkg with slackpkg+, which allows third party packages to be handled by slackpkg. You don't blacklist third party package in this case as slackpkg+ handles this.
I run gpg update every time before update mainly because I use bash history and all the commands are in an && command line, including install-new. It hasn't hurt anything so far.
This actually circumvents the purpose of GPG. From the man page:
Quote:
# slackpkg update gpg
The GPG key doesn't change. This should be a "one time" command - run it once and forget it...
The idea is that you run the command once to obtain Slackware's "true" public key (ignoring all the trust issues around this), which slackpkg subsequently relies on for each update to check that the downloaded files really came from the Slackware team (I didn't look, but I guess it verifies CHECKSUMS.md5.asc, and then the MD5 hashes inside CHECKSUMS.md5 for the individual packages prior to installing. I really wish the Slackware team would stop using MD5 for this purpose, but anyway..).
As an example, let's say someone hacked your favourite mirror and put malware on there: What would normally happen is that they couldn't produce a proper signature which verifies against Slackware's real public key (which your system would have), and slackpkg would notice this and the update would fail. But, if you keep updating the GPG key on every update and the mirror is compromised, then you would overwrite the true Slackware public key with a bogus one from the compromised mirror[1], and then slackpkg will happily install the malware onto your system (since your bogus public key now matches the bogus private key used to sign the malware). In reality slackpkg may warn about this case (the GPG key changing), but I don't know.
Long story short, you only want to run `slackpkg update gpg` one time. That gives you the public key, which is your long-term assurance for genuine downloads as you update from any Slackware mirror.
*edit* [1] This is not true on slackpkg any more, since it grabs the public key from slackware.com instead of the mirror.
This actually circumvents the purpose of GPG. From the man page:
The idea is that you run the command once to obtain Slackware's "true" public key (ignoring all the trust issues around this), which slackpkg subsequently relies on for each update to check that the downloaded files really came from the Slackware team (I didn't look, but I guess it verifies CHECKSUMS.md5.asc, and then the MD5 hashes inside CHECKSUMS.md5 for the individual packages prior to installing. I really wish the Slackware team would stop using MD5 for this purpose, but anyway..).
As an example, let's say someone hacked your favourite mirror and put malware on there: What would normally happen is that they couldn't produce a proper signature which verifies against Slackware's real public key (which your system would have), and slackpkg would notice this and the update would fail. But, if you keep updating the GPG key on every update and the mirror is compromised, then you would overwrite the true Slackware public key with a bogus one from the compromised mirror, and then slackpkg will happily install the malware onto your system (since your bogus public key now matches the bogus private key used to sign the malware). In reality slackpkg may warn about this case (the GPG key changing), but I don't know.
Long story short, you only want to run `slackpkg update gpg` one time. That gives you the public key, which is your long-term assurance for genuine downloads as you update from any Slackware mirror.
It was reading this entry in the man page that prompted my original post - I had unintentionally run the command twice.
So, if i understand correctly: provided that the public key was still genuine, I have not done any harm. However repeatedly running 'slackpkg update gpg' increases the risk that you will download something malicious, even if the probability of this is small.
It was careless of me to do this , but I have learnt something.
Last edited by amikoyan; 08-09-2021 at 12:25 PM.
Reason: spelling
So, if i understand correctly: provided that the public key was still genuine, I have not done any harm. However repeatedly running 'slackpkg update gpg' increases the risk that you will download something malicious, even if the probability of this is small.
Right, the basic problem to be solved is to obtain the correct public key, so repeatedly downloading it goes against that goal (even with slim odds of getting a bogus key).
Also it looks like my info is out of date on -current and regular slackpkg. Testing with slackpkg+ currently gives the old method (key from mirror):
~# slackpkg update gpg
Getting key from https://www.slackware.com/infra/keys/GPG-KEY
Slackware Linux Project's GPG key added
So the thing I mentioned about pulling a bogus key from a hacked mirror is no longer true with regular slackpkg (of course the Slackware server could get hacked too, but anyways).
It was reading this entry in the man page that prompted my original post - I had unintentionally run the command twice.
So, if i understand correctly: provided that the public key was still genuine, I have not done any harm. However repeatedly running 'slackpkg update gpg' increases the risk that you will download something malicious, even if the probability of this is small.
It was careless of me to do this , but I have learnt something.
The point is, it only breaks anything if one or more of the GPG keys have been compromised. If you're an LQ user it's unlikely you won't have noticed that. Keys have been officially updated during my time using Slackware, so if you don't customarily do the update if you get an error don't jump to the conclusion that it's an exploit, check if the keys need to be updated.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.