When running `opkg update` I get "Signature check failed.". Signing key missing?

[assarbad]

Hi, I downloaded the latest medkit to reset a Turris Omnia (original model with 1 GiB of RAM) which I hadn’t used in a while. Configured all the basics through the web interface then.

After that I attempted opkg update and was immediately met with errors:

root@turris:~# opkg update
Downloading https://repo.turris.cz/hbl/omnia/packages/core/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_core
Downloading https://repo.turris.cz/hbl/omnia/packages/core/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/base/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_base
Downloading https://repo.turris.cz/hbl/omnia/packages/base/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/cesnet/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_cesnet
Downloading https://repo.turris.cz/hbl/omnia/packages/cesnet/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/luci/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_luci
Downloading https://repo.turris.cz/hbl/omnia/packages/luci/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/node/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_node
Downloading https://repo.turris.cz/hbl/omnia/packages/node/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/packages/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_packages
Downloading https://repo.turris.cz/hbl/omnia/packages/packages/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/routing/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_routing
Downloading https://repo.turris.cz/hbl/omnia/packages/routing/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/telephony/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_telephony
Downloading https://repo.turris.cz/hbl/omnia/packages/telephony/Packages.sig
Signature check failed.
Remove wrong Signature file.
Downloading https://repo.turris.cz/hbl/omnia/packages/turrispackages/Packages.gz
Updated list of available packages in /var/opkg-lists/turrisos_turrispackages
Downloading https://repo.turris.cz/hbl/omnia/packages/turrispackages/Packages.sig
Signature check failed.
Remove wrong Signature file.

Upon further investigation and finding a script (and unfortunately also removing wget-ssl based on advice in the OpenWRT forum), I was able to investigate this a little further.

I manually downloaded the following two files into /tmp:

wget https://repo.turris.cz/hbl/omnia/packages/turrispackages/Packages.{gz,sig}

… and attempted the steps evident from said script, after unpacking Packages from Packages.gz.

The result was the following error:

# usign -V -P /etc/opkg/keys -m /tmp/Packages
Cannot open file '/etc/opkg/keys/b4140d4dba7ec90e' for reading

which to me suggests that there should be a key with that fingerprint/ID (i.e. b4140d4dba7ec90e) which isn’t present on my system.

Where does this key come from? What’s the procedure to establish trust with previously not known keys?

Anyway, I think it suggests that there is an issue with the image flashed by the medkit, since it’s at least unusual that a mere opkg update should fail right after a fresh installation.

---

I reckon the following is also relevant:

# cat /etc/os-release
NAME="TurrisOS"
VERSION="7.0.0"
ID="turrisos"
ID_LIKE="lede openwrt"
PRETTY_NAME="TurrisOS 7.0.0"
VERSION_ID="7.0.0"
HOME_URL="https://www.turris.cz/"
BUG_URL="https://gitlab.nic.cz/groups/turris/-/issues/"
SUPPORT_URL="https://www.turris.cz/support/"
BUILD_ID="r20300+124-3547565f24"
OPENWRT_BOARD="mvebu/cortexa9"
OPENWRT_ARCH="arm_cortex-a9_vfpv3-d16"
OPENWRT_TAINTS="busybox"
OPENWRT_DEVICE_MANUFACTURER="CZ.NIC"
OPENWRT_DEVICE_MANUFACTURER_URL="https://www.turris.cz/"
OPENWRT_DEVICE_PRODUCT="Turris Omnia"
OPENWRT_DEVICE_REVISION="v0"
OPENWRT_RELEASE="TurrisOS 7.0.0 3547565f245479dc1643ea66828fb55635d49051"

[AreYouLoco]

It was reported already. Latest medkit points to HBL repos. Replace hbl with hbs in /etc/opkg/distfeeds.conf and it should work as expected

[assarbad]

@AreYouLoco thanks so much for pointing that out!

Just for the benefit of whoever also removed wget-ssl as I did. The following adjusted script should fix it:

#!/bin/sh
set -euo pipefail
readonly LISTDIR=/tmp/opkg-lists
rm -f -R -- "$LISTDIR" ||:
mkdir -p -- "$LISTDIR"
while read TYPE REPO URL; do
	for ext in gz sig; do
		( set -x; uclient-fetch -q -O "$LISTDIR/$REPO.$ext" "$URL/Packages.$ext" )
	done
	gzip -kd "$LISTDIR/$REPO.gz"
	if usign -V -P /etc/opkg/keys -m "$LISTDIR/$REPO" 2>&1 | grep -e "^OK$"; then
		( set -x; mv -f -- "$LISTDIR/$REPO.gz" "$LISTDIR/$REPO" )
	else
		echo "FATAL: Signature verification failed:"
		( set -x; usign -V -P /etc/opkg/keys -m "$LISTDIR/${REPO}" )
	fi
done < /etc/opkg/distfeeds.conf

Then I get to see:

# ./opkg-update.sh 
+ uclient-fetch -q -O /tmp/opkg-lists/turrisos_core.gz https://repo.turris.cz/hbl/omnia/packages/core/Packages.gz
+ uclient-fetch -q -O /tmp/opkg-lists/turrisos_core.sig https://repo.turris.cz/hbl/omnia/packages/core/Packages.sig
FATAL: Signature verification failed:
+ usign -V -P /etc/opkg/keys -m /tmp/opkg-lists/turrisos_core
Cannot open file '/etc/opkg/keys/b4140d4dba7ec90e' for reading

(which is of course the same error, but it’s more verbose as was the original intent of that script)

[assarbad]

sed -i 's|hbl|hbs|g' /etc/opkg/distfeeds.conf fixes it. Thanks again, @AreYouLoco

[AreYouLoco]

It was reported here on the forum but not on gitlab. If you feel like let the devs know here by creating an issue:

Issues · Turris / Turris OS / Turris Build · GitLab

[assarbad]

Oh, sure. I can attempt that. But it seemed that one has to wait for an account on the GitLab instance. I’ll apply for an account, though.

Reported here: issue #440