DRAFT: RSA SHA1 signature support is insecure

[xnox]

Currently apk-tools, apko, and melange support verifying APKINDEX and .apk signatures of types:

• RSA - RSA signature using SHA1 message digest
• RSA256 - RSA signature using SHA256 message digest

apko & melange are planning to add support for verifying APKINDEX and .apk signatures using:

• ML-DSA-86 type signature

Universally RSA-SHA1 signatures are no longer considered secure and are being universally withdrawn and removed.

Wolfi & Chainguard apk repositories transitioned to RSA256 signatures on 2025-01-30.

apko & melange would like to add warnings, add security levels, and remove weak verification, but:

• alpinelinux.org repositories are still signed with RSA-SHA1
• JFrog Artifactory repositories are still signed with RSA-SHA1

Users may want to know this, and yet need to continue to use those, and have a managed upgrade path.

[adambkaplan]

Two questions:

• Does the alpine project have a timeline to deprecate/remove SHA1 signatures?
• Do we know how big the impact would be if apko can't validate upstream alpine linux package signatures?

[xnox]

Two questions:

• Does the alpine project have a timeline to deprecate/remove SHA1 signatures?

Alpine tooling - apk-tools has always had RSA-SHA256 support (as far back history as I can track). It is not clear why they chose to sign with SHA1, instead of SHA256.

abuild tooling hat support to create RSA-SHA256 signatures since v3.14 release, contributed by me.

They have been working on apk-tools v3 for a very long time and that switches to SHA512 based signatures - however, as far as I can tell, currently the APKINDEX.tar.gz and .apk are still in the v2 format with RSA-SHA1 signatures.

It is not clear who to contact or ask about upgrading v2 format signatures to RSA-SHA256 or switching to the v3 format and thus SHA512 based signatures. The roadmap for next release is possibly here https://gitlab.alpinelinux.org/alpine/tsc/-/work_items/108 , but also Alpine TSC is currently dissolved https://gitlab.alpinelinux.org/alpine/tsc/-/work_items/107

Note that signature in the v2 APKINDEX.tar.gz is over a plaintext APKINDEX file, which is allowed to have comments - using https://sha-mbles.github.io/ software it is practical to create two APKINDEX.tar.gz with two chosen prefixes; and computed suffixes that will point at different packages yet validated with same signature.

• Do we know how big the impact would be if apko can't validate upstream alpine linux package signatures?

apko does not have any telemetry or call-home; the warning message is the only one-way communication channel to check who uses apko/rules_apko with alpinelinux.

One idea that was floated in private is to still validate signatures, even when "--ignore-signatures" is specified - as a weak CRC, because that's effectively what an RSA-SHA1 signature is.

[xnox]

I am pondering the following strategy:

• compile with GOFIPS140=latest by default
• enforce and reject RSA-SHA1 signatures
• such that customers get an opt-out of this feature with GODEBUG variable, which is self discoverable