I’ve made it more robust and applied all shellcheck suggestions.
I feel a bit worried about ignoring the certificate for installing the keys package. Security-wise, this would be among the most important packages where validation should be top priority.
Maybe hardcode the validation? But I don’t know how often the signing key for these two packages change.
I hope you tested it yourself before applying such changes. Did you?
Well that are keys for verification. How would verify keys which are there for verification?
No idea what you mean by that As I know gpg keys can change quite often. The problem though is that the if you didn’t update and skip one keyring update, it will not be able to verify the keyring package and result in that error.
The approach here downloads the keyring and installs it without verifying if it’s the original package.
I believe this defeats the purpose of the keys.
I have not deep knowledge when it comes to gpg, but in my view it makes no difference if you get the keyring from an unverified package or retrieve it from a server. The verification of the package is just an extra security measure, but the missing of the package verification of keyrings would not reduce security in any way.
The signature is there to verify that it has not been tampered with on the server, client or during transfer.
The public keys make sure of this.
However, if I control the keyring package (because you disabled the verification) I could add my own keys and sign any package (e.g. firefox or keepassxc) and your system will happily install my package.
In the script we switch explicitly to the global mirror which is not a some mirror out there which can be manipulated maybe “easier”. Here I would give Manjaro’s Maintainers a bit trust.
Package verification can be disabled really easy if you have root access.
On the script verification of packages are only temporary disabled. It only affects the keyring packages. So it is minimal invasive.
So to manipulate package, you must have access to Manjaro’s own server… It is a little security concern, but in my view it is better doing it that way as reinstalling the whole system.
If you have a better idea, please say it, but I don’t see any fast, reliable and less invasive solution as that script…
Usually the key exchange should be done with another factor, e.g. hardcoding the keyring’s key into the script.
Another way might be populate the keyrings and then refresh the keys? New keys might be missing but the maintainer of the keyring won’t have new keys very often, right?
If you trust the global mirror, why do you have package signing anyway? Where does your trust stop?
Maybe, but we are talking about pacman where gpg verification is optional and not a requirement. It is by design a security measure on top of it although enabled by default (opt-out).
Well installing the package does population already, but don’t connect to a gpg server and refresh the keys. Doing pacman-key --refresh needs a lot more time by the way.
In my view, Manjaro’s mirror is the origin. There I have more trust and I would consider disabling gpg verification there if necessary. If it is a mirror of Manjaro’s server, then I would really care to check if the package is really one from Manjaro, so that it wasn’t manipulated somewhere in between. Therefore I strongly consider to use gpg verification.
About the script:
Well… maybe add a line to switch to another local mirror before doing a full upgrade?
As I know gpg keys can change quite often. The problem though is that the if you didn’t update and skip one keyring update, it will not be able to verify the keyring package and result in that error.
