[HowTo] Work around gpg verification issue on left behind systems

I was a bit tired of explaining how to solve that issue and created a script, which does the job.

I used full parameters so that total newbies maybe have clue what the commands actually do.

Maybe it can be integrated somewhere or just use for inspiration for a better solution.

#!/usr/bin/env bash

set -o errexit  #>Exit when a command fails (returns non-zero)
set -o pipefail #>Exit when a command within a pipeline fail (returns non-zero)
set -o nounset  #>Forbid to use unset

# Reset language to default
export LANG=C

# Switch to root account
asSudo=("sudo" "--login" "--user=root")

# Colors for messages
HL='\e[1;37;1;45m'
ED='\e[0m'

# Script starts here:
echo -e "${HL}[INFO] Removing lock files of pamac and pacman ${ED}"
"${asSudo[@]}" rm --force --verbose /var/tmp/pamac/dbs/db.lck
"${asSudo[@]}" rm --force --verbose /var/lib/pacman/db.lck

echo -e "${HL}[INFO] Switching to global mirror (Manjaro's CDN) ${ED}"
"${asSudo[@]}" pacman-mirrors --country Global
"${asSudo[@]}" pacman-mirrors --fasttrack 5

echo -e "${HL}[INFO] Remove pacman's gnupg ${ED}"
"${asSudo[@]}" rm --recursive --force --verbose /etc/pacman.d/gnupg

echo -e "${HL}[INFO] Re-initilize pacman's gnupg ${ED}"
"${asSudo[@]}" pacman-key --init

echo -e "${HL}[INFO] Removing pacman's cache ${ED}"
"${asSudo[@]}" pacman --sync --clean --clean --noconfirm

echo -e "${HL}[INFO] Downloading the newest packages which contains the gpg keys ${ED}"
TMPDIR="$(mktemp -d)"
"${asSudo[@]}" cp "/etc/pacman.conf" "${TMPDIR}/pacman.conf"
"${asSudo[@]}" sed --in-place --regexp-extended 's/^(SigLevel).+$/\1 = Never/g' "${TMPDIR}/pacman.conf"
"${asSudo[@]}" pacman --sync --refresh --downloadonly --noconfirm --cachedir "${TMPDIR}" --config "${TMPDIR}/pacman.conf" archlinux-keyring manjaro-keyring

echo -e "${HL}[INFO] Installing Keyring Packages ${ED}"
"${asSudo[@]}" pacman --upgrade --noconfirm --config "${TMPDIR}/pacman.conf" "${TMPDIR}"/*.tar.*

echo -e "${HL}[INFO] Removing temporary directory: ${TMPDIR}${ED}"
"${asSudo[@]}" rm --recursive --force --verbose "${TMPDIR}"

echo -e "${HL}[INFO] Switching to a local mirror by GeoIP ${ED}"
"${asSudo[@]}" pacman-mirrors --geoip
"${asSudo[@]}" pacman-mirrors --fasttrack 5

echo -e "${HL}[INFO] Performing a full upgrade with pamac without AUR ${ED}"
"${asSudo[@]}" pamac upgrade --force-refresh --enable-downgrade --no-aur --no-confirm

echo -e "${HL}[INFO] Done.${ED}"

Also here available: megavolt/random-scripts: Various scripts for any usages. - NotABug.org: Free code hosting

Also possible to run it like that:

curl -s "https://notabug.org/megavolt/random-scripts/raw/master/fix-gpg-pacman.sh" | sh

This is a wiki article and you are invited to make the script better or add more explanations or anything else.

Hope that help someone out there :wink:

5 Likes

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.

1 Like

I hope you tested it yourself before applying such changes. Did you? :slight_smile:

Well that are keys for verification. How would verify keys which are there for verification?

No idea what you mean by that :man_shrugging: 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.

Yes, I’ve tested it.

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.

1 Like

I agreed, but you can improve it or suggest your idea how it could be fixed properly (with check of origin).

1 Like

:+1:

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.

okay understand that, but…

  1. 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.
  2. Package verification can be disabled really easy if you have root access.
  3. 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?

2 Likes

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?

pacman-mirrors --interactive --geoip

:question:

Anyway… added it:

2 Likes