What it does

Checks that architectures (see alpm-architecture) are not specified twice.

Why is this bad?

Duplicate alpm-architecture definitions are confusing and do not serve a purpose. Generally, duplicate definitions are ignored and therefore it is best practice to only specify an architecture once.

Example

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
arch = x86_64

Use instead:

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64

What it does

Ensures that each license in a SRCINFO is a valid SPDX license expression.

Why is this bad?

The license attribution for packages clearly defines under what license(s) a package is distributed. When not using valid SPDX license identifiers to describe the license of a package, it may be unclear what license applies for it. Unclear license attribution has implication for the reuse of the package in binary form and whether source code must be made available for it. For this reason, Arch Linux decided to only allow valid SPDX license expressions (see RFC 0016).

Examples

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
license = Apache

Use instead:

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
license = Apache-2.0

What it does?

Ensures that an architecture (see alpm-architecture) is set in a SRCINFO.

Why is this bad?

An alpm-architecture must be set specifically in a SRCINFO as otherwise any would be implied.

Example

pkgbase = test
pkgver = 1.0.0
pkgrel = 1

Use instead:

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64

What it does

Ensure that no OpenPGP Key ID is used to authenticate and verify upstream artifacts.

Why is this bad?

An OpenPGP certificate can be used to verify and authenticate upstream sources. In PKGBUILD and SRCINFO files these certificates are identified using an ID. This allows the retrieval of matching certificates from remote resources (e.g. Web Key Directory or OpenPGP keyservers).

An OpenPGP Key ID is a short identifier that can be used to identify an OpenPGP certificate. However, its uniqueness cannot be guaranteed and thus it does not guard against collision.

If an OpenPGP certificate cannot be uniquely identified:

• an arbitrary certificate may have a matching OpenPGP Key ID and it would not be possible to use it for authentication and verification of the particular upstream sources.
• sophisticated attackers may be able to craft a certificate with a matching OpenPGP Key ID and swap upstream sources and digital signatures with malicious ones.

Only an OpenPGP fingerprint meaningfully guards against collision and should always be used instead of an OpenPGP Key ID to uniquely identify an OpenPGP certificate.

Example

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
validpgpkeys = 2F2670AC164DB36F

Use instead:

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
validpgpkeys = 4A0C4DFFC02E1A7ED969ED231C2358A25A10D94E

What it does

Ensures that SRCINFO data only contains architecture-specific fields for declared architectures (see alpm-architecture).

Why is this bad?

Architecture-specific fields can be used to provide overrides for a field on a specific alpm-architecture. If the architecture for an architecture-specific field is not specified in a PKGBUILD or SRCINFO, the data of the architecture-specific fields is unused. Such fields are often remnants of architecture removals in the respective PKGBUILD that were not fully cleaned up.

Example

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
# A source property for the aarch64 architecture which isn't specified above.
source_aarch64 = https://domain.tld/testing/aarch_64_test.tar.gz
source_x86_64 = https://domain.tld/testing/x86_64_test.tar.gz

Use instead:

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
source_x86_64 = https://domain.tld/testing/x86_64_test.tar.gz

What it does

Ensures that each alpm-package-source-checksum in SRCINFO data uses a safe hash function.

Why is this bad?

Upstream artifacts are validated against hash digests (see alpm-package-source-checksum) set in PKGBUILD and SRCINFO files.

Some hash functions (e.g. MD-5 and SHA-1) used for creating these hash digests are unsafe to use from a cryptographic perspective. These algorithms should be avoided to prevent hash collisions and potential abuse.

Using unsafe hash algorithms allows attackers to craft malicious artifacts that pass the checksum check. Further, attackers could swap existing artifacts with these malicious artifacts and compromise a package on (re)build.

Example

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
source = https://domain.tld/testing/x86_64_test.tar.gz
md5sums = 10245815f893d79f3d779690774f0b43

Use instead:

pkgbase = test
pkgver = 1.0.0
pkgrel = 1
arch = x86_64
source = https://domain.tld/testing/x86_64_test.tar.gz
sha512sums = 1816c57b4abf31eb7c57a66bfb0f0ee5cef9398b5e4cc303468e08dae2702da55978402da94673e444f8c02754e94dedef4d12450319383c3a481d1c5cd90c82