Untrusted signature error when using Alpine version >3.11

[l00sed]

fetch https://nl.alpinelinux.org/alpine/v3.21/main/x86_64/APKINDEX.tar.gz
ERROR: https://nl.alpinelinux.org/alpine/v3.21/main: UNTRUSTED signature
WARNING: Ignoring APKINDEX.7b2bbd51.tar.gz: No such file or directory

Is the repositories file the only thing that determines the version of Alpine to install?

https://nl.alpinelinux.org/alpine/v3.21/main
https://nl.alpinelinux.org/alpine/v3.21/community

I've also tried with --branch v3.21 and gotten the same "UNTRUSTED signature" error.

It might be related to this issue?

[jirutka]

Do you run alpine-make-vm-image on Alpine Linux or other distro? x86_64 or another architecture?

Is the repositories file the only thing that determines the version of Alpine to install?

alpine-make-vm-image/alpine-make-vm-image

Lines 39 to 41 in 9ebdf2f

	# -b --branch ALPINE_BRANCH Alpine branch to install; used only when
	# --repositories-file is not specified. Default is
	# latest-stable.

[l00sed]

Hey thanks for the response. I found a solution. I was running it on a Vagrant vm, but emulating the x86 architecture from Apple silicon (m3 arm). I was having trouble running an alpine image and decided to use the tool on an Ubuntu x86 image that did spin up successfully.

This is when I received the error. Finally I discovered macpine. This was a much easier way to get the x86 emulated alpine vm running on Apple silicon. From there, I was able to successfully install the alpine image tool with apk.

It ran successfully at this point, and I was able to build a newer image.

[polarathene]

Just leaving this here if it helps (not specific to alpine-make-vm-image).

---

When installing packages for a different arch (eg: apk add --arch aarch64 when the /etc/apk/arch file has x86_64), the /etc/apk/keys is not compatible and you'd get that UNTRUSTED signature error message.

For Alpine 3.22 with x86_64:

$ ls -1 /etc/apk/keys

alpine-devel@lists.alpinelinux.org-4a6a0840.rsa.pub
alpine-devel@lists.alpinelinux.org-5243ef4b.rsa.pub
alpine-devel@lists.alpinelinux.org-5261cecb.rsa.pub
alpine-devel@lists.alpinelinux.org-6165ee59.rsa.pub
alpine-devel@lists.alpinelinux.org-61666e3f.rsa.pub

For Alpine 3.22 with aarch64:

$ ls -1 /etc/apk/keys

alpine-devel@lists.alpinelinux.org-524d27bb.rsa.pub
alpine-devel@lists.alpinelinux.org-58199dcc.rsa.pub
alpine-devel@lists.alpinelinux.org-616a9724.rsa.pub
alpine-devel@lists.alpinelinux.org-616adfeb.rsa.pub
alpine-devel@lists.alpinelinux.org-616ae350.rsa.pub

---

You need to acquire those public keys, or you can install them via the alpine-keys package for that arch, which would require --allow-untrusted to bypass the UNTRUSTED signature error. After that's sorted you'll no longer encounter that failure 👍

docker run --rm -it \
  --env 'SYSROOT=/opt/sysroot/aarch64' \
  --workdir /opt/sysroot \
  alpine:3.22

# Setup a new sysroot for a specific arch:
# `--initdb` will create the `--root` directory (provided the parent dirs exist)
# `--arch` will set the value of `${SYSROOT}/etc/apk/arch` (defaults to `apk --print-arch`)
apk --root="${SYSROOT}" --arch aarch64 add --initdb

# Avoid needing `--repositories-file=/etc/apk/repositories` by adding to the sysroot:
cp /etc/apk/repositories "${SYSROOT}/etc/apk/repositories"

# Acquire the public keys needed to trust the repo arch (`${SYSROOT}/etc/apk/arch`):
apk --root="${SYSROOT}" --allow-untrusted add alpine-keys

# Now you can install packages with trusted signatures:
apk --root="${SYSROOT}" add zlib-static

# Inspect the static library archive objects to verify the correct arch was installed:
readelf --file-header "${SYSROOT}/usr/lib/libz.a" | grep Machine | sort -u | awk '{ print $2 }'

The final command would show AArch64 in this case, even though I used an alpine:3.22 image that was x86_64. The commentary above should make it self-explanatory.

NOTE: The SYSROOT variable name isn't important. If unfamiliar with that it's just referring to a location I'd use for cross-compiling, but --root could just as easily refer to a path for a Root FS tree that could for example be used to create a new container image for runtime purposes.