Arch Linux Dev Blog

Verify Arch Linux artifacts using VOA/OpenPGP

2026-01-11T10:00:00+00:00

In the recent blog post</a> on the work funded by Sovereign Tech Fund (STF</a>), we provided an overview of the "File Hierarchy for the Verification of OS Artifacts" (VOA</a>) and the voa project</a> as its reference implementation.

VOA</a> is a generic framework for verifying any kind of distribution artifacts (i.e. files) using arbitrary signature verification technologies.

The voa</code> CLI ⌨️</h2>The voa project</a> offers the voa(1)</code></a> command line interface (CLI) which makes use of the voa(5)</a> configuration file format for technology backends. It is recommended to read the respective man pages to get an overview. The following sections assume an Arch Linux system, with the voa-verifiers-arch</a> and voa</a> packages installed. On other systems, it is possible to download the "voa-verifiers-arch" artifact of the latest release of archlinux-keyring</a> and to place its contents in one of the relevant VOA load paths</a>. Afterwards, follow the installation instructions</a> for the voa(1)</code></a> CLI. Using VOA with the OpenPGP technology 🤝</h2> In this article we will focus on the use of VOA</a> with the OpenPGP technology backend for signature verification. This backend is available as part of the reference implementation of VOA</a> in the voa project</a>. The big picture concepts in VOA</a> are shared between all technology backends. However, some capabilities and details differ depending on technology. We will start by looking at some common interactions with VOA</a>: Verifying the signatures of an Arch Linux package and installation medium.</li> Inspecting the verification configuration.</li> Inspecting verifiers.</li> Importing additional verifiers.</li> </ul> As an advanced usage example, we will look into setting up a custom VOA</a> context for an unofficial package repository, with a separate policy configuration. Additionally, we will take a brief glance at a way to verify all official Arch Linux package files for testing in a development environment. Finally, we will provide a short overview of the state of other technology backends. Verifying signatures 🔏</h2> The voa-verify(1)</code></a> command can be used to verify an artifact against a signature. Arch Linux relies on a configuration file for the OpenPGP technology backend (see arch.yaml</a>) to enforce its own verification policy. Based on this configuration, a single package file can be verified against the corresponding detached OpenPGP data signature</a> using: voa verify arch package default openpgp /var/cache/pacman/pkg/systemd-259-1-x86_64.pkg.tar.zst{,.sig} ✅ /var/cache/pacman/pkg/systemd-259-1-x86_64.pkg.tar.zst.sig 1766039593 02fd1c7a934e614545849f19a6234074498e9cee 0429897de5f3bdac537a30696d42bdd116e0068f</code></pre> The output lists: The detached signature file used for verification,</li> the signature's creation time,</li> the OpenPGP fingerprint</a> of the primary key of the OpenPGP certificate</a>, and</li> the OpenPGP fingerprint</a> of the component key used for signing.</li> </ul> Similarly, the monthly installation medium can be verified, based on the designated verifiers: voa verify arch image installation-medium openpgp archlinux-2026.01.01-x86_64.iso{,.sig} ✅ archlinux-2026.01.01-x86_64.iso.sig 1767267369 3e80ca1a8b89f69cba57d98a76a5ef9054449a5c 3e80ca1a8b89f69cba57d98a76a5ef9054449a5c</code></pre>Inspecting the configuration of VOA technology backends 📄</h2> In the verification examples above, the voa-verify(1)</code></a> command implicitly relied on two inputs: A voa(5)</a> configuration file, which specifies which exact rules the OpenPGP technology is supposed to enforce in the context of the Arch Linux distribution.</li> A set of OpenPGP certificates</a> that are used to determine if signatures are valid.</li> </ul> In this section we will look at the first point: The configuration that is active when verifying signatures with VOA in a given context. As a uniform user-facing model for these settings, the voa project</a> includes the voa(5)</a> configuration file format, which defines exactly how verification with technology backends is done. A backend technology like OpenPGP can offer a range of different approaches to package verification, such as: Are specific identities required on valid verifiers?</li> Are trust anchors expected to authenticate the artifact verifiers?</li> </ul> Arch Linux uses the following configuration file in /usr/share/voa/arch.yaml</code>, which describes the policy VOA uses for signature verification of Arch Linux artifacts: default_technology_settings: openpgp: num_data_signatures: 1 verification_method: trust_anchor: required_certifications: 3 artifact_verifier_identity_domain_matches: - archlinux.org trust_anchor_fingerprint_matches: # Levente Polyak (Arch Linux Master Key) <anthraxx@master-key.archlinux.org> - d8afdda07a5b6edfa7d8ccdad6d055f927843f1c # Leonidas Spyropoulos (Arch Linux Master Key) <artafinde@master-key.archlinux.org> - 3572fa2a1b067f22c58af155f8b821b42a6fdcd7 # Johannes Löthberg (Arch Linux Master Key) <demize@master-key.archlinux.org> - 69e6471e3ae065297529832e6ba0f5a2037f4f41 # David Runge (Arch Linux Master Key) <dvzrv@master-key.archlinux.org> - 2ac0a42efb0b5cbc7a0402ed4dc95b6d7be9892e # Florian Pritz (Arch Linux Master Key) <florian@master-key.archlinux.org> - 91ffe0700e80619ceb73235ca88e23e377514e00</code></pre> The voa-config(1)</code></a> command allows introspection of the configuration in a given context. The command returns an explanation of the active policy: voa config show arch OpenPGP settings 🔏 Each artifact requires 1 valid data signature(s) from artifact verifiers to be successfully verified. ✅ Each artifact is verified using the "trust anchor" verification method. 📧 A valid certificate must have a valid User ID that uses one of the following domains and has 3 certification(s) from individual trust anchors on it for the certificate to be considered as artifact verifier: ⤷ archlinux.org 🐾 A valid certificate must match one of the following OpenPGP fingerprints to be considered as trust anchor: ⤷ 2ac0a42efb0b5cbc7a0402ed4dc95b6d7be9892e ⤷ 3572fa2a1b067f22c58af155f8b821b42a6fdcd7 ⤷ 69e6471e3ae065297529832e6ba0f5a2037f4f41 ⤷ 91ffe0700e80619ceb73235ca88e23e377514e00 ⤷ d8afdda07a5b6edfa7d8ccdad6d055f927843f1c 📝 The following sources have been considered for the creation of the settings: ⤷ Config file: /usr/share/voa/arch.yaml ⤷ Built-in defaults</code></pre> It can also be used to list the origins of all available configurations available to a user: voa config list 🖥 arch ⤷ Config file: /usr/share/voa/arch.yaml ⤷ Built-in defaults 🖥 example ⤷ Config file: /home/user/.config/voa/example.yaml ⤷ Built-in defaults</code></pre>Listing verifiers 👁️‍🗨️</h2> VOA specifies a hierarchical directory structure. For each type of artifact, a specific subset of this structure provides a set of "verifiers" that must be used for artifact verification. Verifiers may reside in various load paths</a> on the system. To view a list of verifiers in a particular context, use voa-list(1)</code></a>. E.g. to show the paths of all verifiers considered for package verification on an OS named "test", use: voa list test package</code></pre> To do the same for the Arch Linux distribution, use: voa list arch package</code></pre> To show the paths of all trust anchors considered for authenticating verifiers to use for signature verification of Arch Linux packages, use: voa list arch trust-anchor-package</code></pre>Importing certificates as verifiers ↩️</h2> Using voa-import(1)</code></a> it is possible to import an OpenPGP certificate</a> into the appropriate location in a VOA hierarchy, for use as a verifier. Note, that based on the precedence of the VOA load paths</a>, it is possible to import versions of an existing OpenPGP certificate</a> into different file system locations. The content of such variants will usually be merged at runtime by the VOA OpenPGP backend. Here, the voa-openpgp</a> crate supports the import of certificates in different formats: An OpenPGP certificate</a> in a single file.</li> A directory containing OpenPGP packets</a> of a single OpenPGP certificate</a>.</li> The custom destructured directory structure for a single OpenPGP certificate</a> as used in archlinux-keyring</a>.</li> </ul> The following examples each import an OpenPGP certificate</a> as verifier for package files on an OS named "test" to the runtime load path of the current user. Importing a single certificate 🔐</h3> Assuming that alice.cert</code> is a file that contains an OpenPGP certificate</a>, we can import it e.g. as a verifier for package files in any repository: voa import --runtime --input alice.cert --context default test package</code></pre>Importing a split certificate 🔐</h3> Certificates may be split up into individual files that contain OpenPGP packets</a>, collectively stored in a directory. Here, we assume that the directory alice/</code> contains the split files. ls alice/ alice.cert-000000-PublicKey alice.cert-000001-UserId alice.cert-000002-Signature voa import --runtime --input alice/ --context default test package</code></pre>Importing a certificate from the archlinux-keyring structure 🔐</h3> The archlinux-keyring</a> project chose to arrange the OpenPGP packets</a> of each tracked OpenPGP certificate</a> in a particular directory structure. After cloning the repository, it is possible to directly import the packets of an OpenPGP certificate</a> from these directory structures, e.g.: git clone https://gitlab.archlinux.org/archlinux/archlinux-keyring/ cd archlinux-keyring/ voa import --runtime --input keyring/packager/dvzrv/991F6E3F0765CF6295888586139B09DA5BF0D338/ --context default test package</code></pre>Setting up a custom verification context ✨️</h2> In the following example we will add an override voa(5)</a> configuration file and an additional OpenPGP certificate</a> to the VOA</a> hierarchy. These additions will define a working signature verification policy for an unofficial repository on Arch Linux. Here, we will define a policy for a custom package repository named "my-repo". We specify a "context" for this repository, in which we override the default Arch Linux voa(5)</a> configuration. By storing the following configuration as /etc/voa/arch.yaml.d/10-my-repo.yaml</code> we provide a specific override for this unofficial package repository: contexts: - purpose: package context: my-repo technology_settings: openpgp: num_data_signatures: 1 verification_method: plain: identity_domain_matches: - example.org fingerprint_matches: - f1d2d2f924e986ac86fdf7b36c94bcdf32beec15</code></pre> We can inspect this policy with voa-config(1)</code></a>, and see how it differs from the one used by Arch Linux: voa config show --purpose package --context my-repo arch OpenPGP settings 🔏 Each artifact requires 1 valid data signature(s) from artifact verifiers to be successfully verified. ✅ Each artifact is verified using the "plain" verification method. 📧 A valid certificate must have a valid User ID that uses one of the following domains to be considered as artifact verifier: ⤷ example.org 🐾 A certificate must match one of the following OpenPGP fingerprints to be considered as artifact verifier: ⤷ f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 📝 The following sources have been considered for the creation of the settings: ⤷ Drop-in config file: /etc/voa/arch.yaml.d/10-my-repo.yaml ⤷ Built-in defaults</code></pre> Assuming a valid OpenPGP certificate</a> with the OpenPGP fingerprint</a> f1d2d2f924e986ac86fdf7b36c94bcdf32beec15</code> is present (e.g. in /etc/voa/arch/package/my-repo/openpgp/f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.openpgp</code>), it is now possible to verify signatures for package files with it: voa verify arch package my-repo openpgp my-package-1.0.0-1-x86_64.pkg.tar.zst{,.sig} ✅ my-package-1.0.0-1-x86_64.pkg.tar.zst.sig 1767267369 f1d2d2f924e986ac86fdf7b36c94bcdf32beec15 f1d2d2f924e986ac86fdf7b36c94bcdf32beec15</code></pre>dev-scripts 👷</h2> The ALPM project</a> includes the dev-scripts</a> testing tool for developers. It allows running tests against several targets, including the OpenPGP verification of all packages in the official repositories. To try this out, clone the project's repository and download all packages in the official repositories. Note: Be aware that this downloads around 100GB of data! You can limit the download amount by only targeting a specific repository (e.g. core</code>). git clone https://gitlab.archlinux.org/archliunx/alpm/alpm cd alpm cargo run --release --bin dev-scripts -- test-files download packages</code></pre> Once downloaded, it is possible to verify all package files with their corresponding detached OpenPGP data signature</a>. cargo run --release --bin dev-scripts -- test-files test signatures Finished `release` profile [optimized] target(s) in 0.36s Running `/home/user/Downloads/alpm/.cargo/runner.sh target/release/dev-scripts test-files test signatures` [00:00:41] [████████████████████████████████████████] (15037/15037, ETA 0s)</code></pre> Verification speed will vary depending on your available resources. Further technology backends 🚀</h2> VOA</a> is designed as a generic and extensible solution for the verification of OS artifacts. Other OSes are encouraged to use it for their respective needs. At the time of writing, only the OpenPGP technology backend is fully specified and implemented in the voa project</a>. The voa-openpgp</a> crate itself is currently still awaiting the integration of the "Web of Trust" verification method based on the novel "Berblom"</a> algorithm. A proof of concept for an X.509 technology backend</a> exists and we hope to progress on its full specification and integration this year. In addition, external contributors have shown interest in adding a technology backend for signify (see voa#24</a>). If you are an expert in a specific signature technology, and want to collaborate, be sure to reach out! We would love to hear from you.

A year of work on the ALPM project 2026-01-10T09:00:00+00:00 In 2024 the Sovereign Tech Fund</a> (STF) started funding</a> work on the ALPM project</a>, which provides a Rust</a>-based framework for Arch Linux Package Management. Refer to the project's FAQ</a> and mission statement</a> to learn more about the relation to the tooling currently in use on Arch Linux. The funding</a> has now concluded, but over the time of 15 months allowed us to create various tools and integrations that we will highlight in the following sections. We have worked on six milestones with focus on various aspects of the package management ecosystem, ranging from formalizing, parsing and writing of file formats, over cryptographic verification of distribution artifacts, to package file and system package management handling: "Formal specifications for packaging data formats"</a></li> "Basic OpenPGP verification of artifacts"</a></li> "Rust library for handling of individual packages"</a></li> "Python bindings for alpm-srcinfo"</a></li> "Distribution-agnostic OpenPGP stack for the verification of distribution artifacts"</a></li> "Rust library for system package management"</a></li> </ul> We are considering ourselves as part of a larger free software ecosystem. We believe that it makes sense to create value not only for our own niche, but for the greater good. As such, we focused on finding generic solutions to the technological problems we are facing as a distribution. We are incredibly grateful for the support from STF without which this type of extensive ground work would not have been possible. ALPM stats 📊</h2> A lot of work has been done over the time of the STF funding</a>. Below are a few statistics about the work done on the ALPM project</a>. </iframe> $ git shortlog --after="2024-10-01" --summary --numbered 467 David Runge 252 Arne Beer 173 Orhun Parmaksız 117 Jagoda Ślązak 54 renovate 16 Laura Demkowicz-Duffy 14 David Schaefer 10 Christian Heusel 5 Heiko Schaefer 4 Morgan Adamiec 1 Adam Perkowski 1 Daniel Maslowski 1 Dominik Peteler 1 Jakub Klinkovský 1 Rafael Epplée</code></pre>$ tokei ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Language Files Lines Code Comments Blanks ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ BASH 1 37 21 10 6 C 2 9 8 0 1 C Header 1 2 1 0 1 CSS 4 2310 1704 175 431 FreeMarker 22 922 557 0 365 JavaScript 16 952 728 104 120 JSON 3 1108 1108 0 0 Just 3 1444 1072 153 219 Meson 1 4 4 0 0 Python 31 6041 4871 70 1100 Sass 1 88 46 30 12 SVG 26 26 26 0 0 Plain Text 4 770 0 615 155 TOML 32 1309 1089 81 139 XML 2 27 27 0 0 YAML 1 1053 798 0 255 ───────────────────────────────────────────────────────────────────────── HTML 35 1544 1459 34 51 |- CSS 1 6 6 0 0 |- JavaScript 5 41 36 2 3 (Total) 1591 1501 36 54 ───────────────────────────────────────────────────────────────────────── Markdown 95 10253 0 7000 3253 |- BASH 20 1052 929 40 83 |- HTML 1 15 10 3 2 |- INI 10 348 335 5 8 |- JSON 1 34 34 0 0 |- Rust 12 769 655 41 73 |- Shell 2 5 5 0 0 |- TOML 1 423 197 166 60 |- YAML 1 17 17 0 0 (Total) 12916 2182 7255 3479 ───────────────────────────────────────────────────────────────────────── Rust 271 46298 38583 1700 6015 |- Markdown 235 15360 142 11744 3474 (Total) 61658 38725 13444 9489 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Total 551 92267 54468 21973 15826 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</code></pre>Specifications 📝</h2> Already in July we reported on the state of the specifications on the devblog</a> and how they enable a deeper, shared view onto our current package management stack in Arch Linux. A lot of custom file formats are in use in our ecosystem. Understanding how to use them is key to maintaining existing and envisioning new technology. Interested developers and package maintainers are encouraged to browse them by file formats</a> or concepts</a>. Meanwhile, the alpm(7)</a> specification provides a good high-level entry-point to the entire topic. We hope this empowers a much larger group of contributors to participate in discussions about the concepts behind Arch Linux's package management. Additionally, we want to enable interested developers to participate in hacking both on the ALPM project</a> itself, as well as make it much easier to experiment with new applications that are built on top of it. Foundational libraries 📚️</h2> In the ALPM project</a> we chose a bottom-up, library first approach, in which libraries for basic tasks have been created iteratively in a workspace. As more libraries for specific use-cases emerge, it becomes possible to build more elaborate or special purpose tools with them. We invite interested Rust developers to have a look at the dedicated API documentation</a> to gain a better understanding and overview of the available libraries and their dependencies. The central alpm-types</a> library provides shared low-level types, which are used in some or all file formats used by the Arch Linux package management stack. These common types make it easy to build other, interoperable libraries on top of it. In alpm-common</a>, central traits and utility functionality are made available to other libraries in the workspace. After some consideration and research, we chose the winnow</a> parser combinator library to create parsers for the various custom file formats. Shared functionality for parsers is made available in the alpm-parsers</a> library. Package management systems usually revolve around central dependency resolver functionality. With alpm-solve</a> we have created a new approach to this for Arch Linux, which is based on the generic resolvo</a> library. Compression is an integral part of the packaging workflow. It ensures that an alpm-package(7)</a> or alpm-repo-db(7)</a> file can be transferred over the network as fast as possible by reducing its size. With the alpm-compress</a> library we have implemented extensible (de)compression for these files. To allow extraction of metadata and data files from an alpm-package(7)</a> file, as well as (rudimentary) package creation, we have created the alpm-package</a> crate. With it, it is possible to create package files from prepared input directories (which already contain relevant metadata and data files). In addition, it is possible to effortlessly iterate over the data files contained in a package file and to extract validated metadata. The creation process of an alpm-package(7)</a> file requires to add root-owned files to a directory (e.g. as part of the installation process of an upstream project's build system). However, one does not want to run the package build process as root, but as an unprivileged user. For this purpose we have created the rootless-run</a> library, which generically abstracts running commands "as root" with the help of different backends (e.g. fakeroot(1)</code></a> and rootlesskit</code>). Libraries and command line interfaces 💻️</h2> Based on specifications of file formats currently used in Arch Linux, we have created libraries that allow their parsing, validation and writing. Notably, we distinguish between: File formats used in an alpm-source-repo(7)</a> (i.e. SRCINFO(5)</a>, PKGBUILD(5)</a>),</li> those in an alpm-repo-db(7)</a> (i.e. alpm-repo-desc(5)</a> and alpm-repo-files(5)</a>),</li> those in an alpm-db(7)</a> (i.e. ALPM-MTREE(5)</a>, alpm-db-desc(5)</a> and alpm-db-files(5)</a>) and</li> those in an alpm-package(7)</a> (i.e. ALPM-MTREE(5)</a>, BUILDINFO(5)</a> and PKGINFO(5)</a>).</li> </ul> The alpm-srcinfo</a> crate provides a library and command line interface for the parsing, validation and creation of SRCINFO(5)</a> files from PKGBUILD(5)</a> scripts. Due to the dynamic nature of the PKGBUILD(5)</a> scripts, the SRCINFO(5)</a> format is surprisingly complex (both to create and to evaluate). The creation of SRCINFO(5)</a> files from PKGBUILD(5)</a> scripts is enabled via the alpm-pkgbuild-bridge</a> project, the alpm-pkgbuild</a> crate and a translation layer</a> in alpm-srcinfo</a>. We have created dedicated documentation</a> for the aspects of parsing and providing its data from different contexts. The alpm-buildinfo</a> crate provides a library and command line interface for the parsing, validation and creation of BUILDINFO(5)</a> files. This file format is contained in an alpm-package(7)</a> and describes its build environment. In the context of reproducible builds</a> it is used to recreate the build environment. The alpm-mtree</a> crate provides a library and command line interface that allows parsing, validation and creation of ALPM-MTREE(5)</a> files. This file format is a subset of the mtree(5)</a> file format, provided by libarchive. As it can be considered more of a meta language than a data format, we rely on bsdtar(1)</code></a> to write that file format. An ALPM-MTREE(5)</a> file is contained in an alpm-package(7)</a>, as well as an entry of an alpm-db(7)</a> and represents a record of all files contained in the package during package creation time. After installing a package to a system, this file can be used to verify ownership and mode of files installed by the package and detect any missing files. The alpm-pkginfo</a> crate offers a library and command line interface for the parsing, validation and creation of PKGINFO(5)</a> files. This file format is contained in an alpm-package(7)</a> and describes all relevant metadata of a package (e.g. alpm-package-relation(7)</a>, alpm-package-name(7)</a>, alpm-package-version(7)</a>). Each system based on alpm(7)</a> maintains its state using an alpm-db(7)</a>. This state encompasses information on each package: the contained files (see alpm-db-files(5)</a>)</li> general metadata (see alpm-db-desc(5)</a>)</li> a record that can be used to validate files of a package (see ALPM-MTREE(5)</a>)</li> </ul> With the alpm-db</a> crate, it is possible to parse, validate and create the alpm-db-desc(5)</a> and alpm-db-files(5)</a> file formats. Additionally, we have worked on database access for the alpm-db(7)</a> structure following the ACID</a> characteristics. Packages for compiled languages (e.g. C or C++) usually contain files in the Executable and Linkable Format (ELF</a>). These files may expose soname</a> information which may be used as alpm-package-relation(7)</a> (see alpm-sonamev1(7)</a> and alpm-sonamev2(7)</a> for the two currently understood formats). With the alpm-soname</a> crate we have focused on the handling and extraction of information for the more modern alpm-sonamev2(7)</a> format as well as plain soname information. As a library and CLI, this crate offers easy access to this ELF</a> data, which plays an important role in figuring out the run-time dependencies of packages. Each alpm-repo(7)</a> contains a set of alpm-package(7)</a> files, digital signatures and a package repository database (see alpm-repo-db(7)</a>). An alpm-repo-db(7)</a> tracks information on particular, unique packages: the contained files (see alpm-repo-files(5)</a>)</li> general metadata (see alpm-repo-desc(5)</a>)</li> </ul> Using the alpm-repo-db</a> crate, it is possible to parse, validate and write alpm-repo-desc(5)</a> and alpm-repo-files(5)</a> files. This crate provides both a library and CLI tool. In the future, it will be extended to allow the creation, reading and writing of alpm-repo-db(7)</a> files. Development integration 👷</h2> To test integration of our libraries against real world data, we have created the dev-scripts</a> crate. It lives in the context of the ALPM project</a>, and is intended as development testbed for assumptions of the various libraries. As such, the crate does not get any releases. The test integration makes it easy to download and prepare live data: package source repositories (official and all of the AUR)</li> official binary package repositories</li> </ul> Currently, it is possible to verify SRCINFO(5)</a> files in package source repositories of the official repositories and all of the AUR</li> ALPM-MTREE(5)</a>, BUILDINFO(5)</a> and PKGINFO(5)</a> files in binary packages in the official repositories</li> the OpenPGP signatures of all packages in the official repositories</li> alpm-db-desc(5)</a> and alpm-db-files(5)</a> files in the entries of a local alpm-db</a></li> alpm-repo-desc(5)</a> and alpm-repo-files(5)</a> files in the entries of the alpm-repo-db(7)</a> files of the official repositories</li> </ul> Python bindings 🐍</h2> We provide Python bindings to make our modern Rust-based parsers and verified types available for use in some other projects of the distribution. Arch Linux's largest Python-based project, with arguably also the largest user-base, is the AURweb</a>, which powers the Arch User Repository (AUR</a>). The web application deals with user input, e.g. via SRCINFO(5)</a> files and currently relies on the native Python library python-srcinfo</a>. (As a sidenote: If you are a Python developer and interested in helping maintain a FastAPI</a> based web application, please reach out to the project! We are always looking for further contributors and maintainers!) The Python bindings for the ALPM project</a> are available on PyPI as python-alpm</a>. With them, we have focused on providing SRCINFO(5)</a> support by relying on the alpm-srcinfo</a> library and by proxy expose a lot of types from the alpm-types</a> library as well. The integration of the python-alpm</a> library into the AURweb</a> application is currently prepared (see aurweb!876</a>). If you are a Python developer and have specific needs for the integration of other libraries of the ALPM project</a>, we would love to hear from you</a>! Linting 🧶</h2> Linters are tools that shift some tedious responsibilities (e.g. quality control) from humans to automation. They are used to automatically detect common mistakes and deviations from established best practices. The goal of linting is to support humans in performing a task well, keeping them on a level with changes in best practices, and empowering them to produce better quality results with less manual effort. The usability and robustness of a distribution like Arch Linux currently relies heavily on the diligence of its package maintainers. Only if package maintainers make an effort to stay up to date with recent developments in packaging (e.g. best practices for languages or PKGBUILD(5)</a> scripts) can the resulting package files maintain a high quality standard. Relying on the written specifications</a>, foundational libraries</a>, as well as libraries and command line interfaces</a> we decided to create a framework for lints, that centrally exposes its knowledge database and allows to flexibly create new rules for various purposes. As such, another central goal of this framework is to provide a single, central tool that covers all aspects of Arch Linux package management. With the alpm-lint</a> crate, a central library and command line interface has been created, that thoroughly documents its architecture</a> and how to add new lint rules</a>. A custom, central website provides details about all currently existing lints, derived from the code documentation of the lint rules: https://alpm.archlinux.page/lints/</a> Using the alpm-lint(1)</code></a> CLI, package maintainers are enabled to validate various scopes relevant to packaging (e.g. contents of an alpm-source-repo(7)</a> or an alpm-package(7)</a> file). The crate currently only offers a small set of lints and we encourage interested package maintainers with a background in Rust to write further lints. Translations 🌐</h2> We are targeting the English language as first language for the project, but many people that are exposed to its error handling and command line interfaces are not native English speakers, or do not speak the language at all. While writing libraries and command line interfaces for various purposes in the context of the ALPM project</a> we realized that we needed to improve the translation (aka. internationalization or i18n) story of the project. After some research on current technologies used for software translation, we have settled on the fluent</a> framework and created a convenient integration for our purposes with the custom fluent-i18n</a> crate. Interested users can now start translating the project on weblate</a>, following our dedicated contributing guidelines on localizations and translations</a>: https://hosted.weblate.org/projects/alpm/</a> VOA 🔏</h2> Arch Linux uses OpenPGP for the verification of its packages. The current OpenPGP integration hinges on a central GnuPG-based keyring. This solution suffers from several shortcomings: The keyring is context-independent. It is not possible to represent different verification contexts with it, e.g. package repository metadata that is signed with a different set of keys than those used for signing packages, or packages in unofficial repositories are signed by a different set of keys than those used for the official repositories.</li> The keyring and its behavior is specific to the GnuPG tool, and in part unspecified. The setup cannot be reliably used with other OpenPGP implementations.</li> The keyring is stateful, and while its contents are populated by data from the package for archlinux-keyring</a>, the entire mechanism requires a root-run agent service.</li> The GnuPG upstream has denounced the IETF-driven OpenPGP standardization process and has subsequently been removed from other major package management software such as apt(8)</code></a> and rpm(8)</code></a> over the last three years. Compatibility with other OpenPGP implementations is no longer guaranteed (see e.g. the ArchWiki article on GnuPG</a> for details)</li> </ul> Already before 2024, the idea emerged to verify digital signatures not with a stateful keyring mechanism, but to instead use a stateless directory structure containing verifiers (see keyringctl#3</a>). This idea was discussed with a set of cross-distribution developers during Image-based Linux Summit 2024</a> and extended from the initial idea of a lookup directory only for OpenPGP to a more general, technology-agnostic mechanism. In a nutshell, we set out to create a directory structure containing e.g. OpenPGP certificates</a>, SSH pubkeys or X.509 certificates, which clearly describes in what context such verifiers are used when verifying artifacts of a distribution. A more in-depth discussion and rundown of the topic can be found in the talk "Verification of OS artifacts without stateful keyrings"</a> from All Systems Go!</a> 2025. UAPI specification ✍️</h3> In late 2024 we started work on a specification</a> to describe this new, technology-agnostic signature verification mechanism and to collect input from relevant stakeholders in several of the more complex technologies that we wanted to cover. The initial version of the specification "File Hierarchy for the Verification of OS Artifacts (VOA)"</a> has been made available in June 2025 and covers the integration of OpenPGP as a first technology backend. Further technology backend specifications are available as drafts, but need more work to iron out open questions. If you have expertise with the use of SSH, X.509, minisign or signify for the signing of artifacts and have an interest in working on a Rust codebase, please reach out and help stabilize these additional backends! VOA reference implementation ⌨️</h3> In July 2025 we started work on the VOA project</a>, as a reference implementation of the UAPI specification. Here are some statistics about the project: </iframe> $ git shortlog --summary --numbered 190 David Runge 17 Heiko Schaefer 3 renovate 2 David Schaefer</code></pre>$ tokei ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Language Files Lines Code Comments Blanks ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ JSON 1 16 16 0 0 Just 1 849 580 109 160 Plain Text 4 770 0 615 155 TOML 12 364 309 14 41 YAML 5 110 110 0 0 ───────────────────────────────────────────────────────────────────────── Markdown 15 1340 0 847 493 |- BASH 2 133 30 101 2 |- Rust 4 200 156 18 26 |- Shell 1 3 3 0 0 |- YAML 1 94 94 0 0 (Total) 1770 283 966 521 ───────────────────────────────────────────────────────────────────────── Rust 70 13685 11301 478 1906 |- Markdown 69 2832 29 2229 574 (Total) 16517 11330 2707 2480 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ Total 108 20396 12628 4411 3357 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━</code></pre> Central handling of the VOA hierarchy is implemented in the technology-independent voa-core</a> library. It serves as an abstraction to access verifiers from the filesystem. The use of OpenPGP-specific verifiers has been implemented in the voa-openpgp</a> library. It handles artifact verification based on several different methods: "plain": Artifacts are verified directly with artifact verifiers, without additional trust anchors. Artifact verifiers can be filtered using OpenPGP fingerprints</a> or domain name matches for OpenPGP User ID</a>s.</li> simple "trust anchor": Artifacts are verified using artifact verifiers, which in turn must be certified by trust anchors. Artifact verifiers can be filtered using domain name matches for OpenPGP User ID</a>s and trust anchors can be filtered using OpenPGP fingerprints</a>. Additionally, the number of required individual certifications for User IDs on each artifact verifier can be specified.</li> "Web of Trust": Artifacts are verified using artifact verifiers, which must reach a sufficient level of trust according to an OpenPGP "Web of Trust" implementation. Artifact verifiers can be filtered using domain name matches for OpenPGP User ID</a>s and trust anchors can be filtered using OpenPGP fingerprints</a>. Additionally, the target trust amount, the trust amount of trusted introducers and the trust amount of filtered trust anchors can be set to a custom value.</li> </ul> Orthogonal to the trust models outlined above, it is possible to specify the required number of independent and valid OpenPGP data signatures per artifact. On Arch Linux we are currently using the Web of Trust implementation that GnuPG offers, on the basis of a GnuPG-specific keyring. However, for all intents and purposes, we are not making use of the features that the full "Web of Trust" model provides. Apart from basic temporal OpenPGP semantics and cryptographic validity, the following rules apply in archlinux-keyring: There is a set of three or more certificates that serve as trust anchors.</li> There is a set of packager certificates that each must have an OpenPGP User ID</a> with an email that uses the "archlinux.org" domain and has three or more third-party certifications from trust anchors.</li> </ul> So in practice, Arch Linux relies on a "Web of Trust" with exactly one level of indirection, and manually curated sets of trust anchors and artifact verifiers. With voa-openpgp, Arch's verification requirements are best modeled with the simple “trust anchor” model. As an additional feature, we have implemented the import of OpenPGP certificates</a> as verifiers into VOA hierarchies from different sources. The import supports OpenPGP certificates</a> split into OpenPGP packets and the custom directory structure used by archlinux-keyring. With the voa-config</a> library we have added support for a central configuration file format with which settings for VOA technology backends can be supplied. The file format (see voa(5)</a>) allows flexible overrides that specify custom rules for any type of context in an OS. The following configuration describes the current policy for the Arch Linux distribution (see arch.yaml</a>): default_technology_settings: openpgp: num_data_signatures: 1 verification_method: trust_anchor: required_certifications: 3 artifact_verifier_identity_domain_matches: - archlinux.org trust_anchor_fingerprint_matches: # Levente Polyak (Arch Linux Master Key) <anthraxx@master-key.archlinux.org> - d8afdda07a5b6edfa7d8ccdad6d055f927843f1c # Leonidas Spyropoulos (Arch Linux Master Key) <artafinde@master-key.archlinux.org> - 3572fa2a1b067f22c58af155f8b821b42a6fdcd7 # Johannes Löthberg (Arch Linux Master Key) <demize@master-key.archlinux.org> - 69e6471e3ae065297529832e6ba0f5a2037f4f41 # David Runge (Arch Linux Master Key) <dvzrv@master-key.archlinux.org> - 2ac0a42efb0b5cbc7a0402ed4dc95b6d7be9892e # Florian Pritz (Arch Linux Master Key) <florian@master-key.archlinux.org> - 91ffe0700e80619ceb73235ca88e23e377514e00</code></pre>VOA high-level API and CLI 🖥️</h3> In the voa</a> crate we provide a high-level API for consumers of VOA and a command line interface. With voa(1)</code></a>, it is possible to: Inspect technology backend configuration settings.</li> Import OpenPGP certificates</a> as VOA verifiers.</li> List all VOA verifiers (by OS or specific context).</li> Verify a file using a detached OpenPGP signature and suitable VOA verifiers.</li> </ul> All subcommands support JSON output. The following example illustrates the semantics of the default VOA technology backend settings for Arch Linux as shown in the previous section: $ voa config show arch OpenPGP settings 🔏 Each artifact requires 1 valid data signature(s) from artifact verifiers to be successfully verified. ✅ Each artifact is verified using the "trust anchor" verification method. 📧 A valid certificate must have a valid User ID that uses one of the following domains and has 3 certification(s) from individual trust anchors on it for the certificate to be considered as artifact verifier: ⤷ archlinux.org 🐾 A valid certificate must match one of the following OpenPGP fingerprints to be considered as trust anchor: ⤷ 2ac0a42efb0b5cbc7a0402ed4dc95b6d7be9892e ⤷ 3572fa2a1b067f22c58af155f8b821b42a6fdcd7 ⤷ 69e6471e3ae065297529832e6ba0f5a2037f4f41 ⤷ 91ffe0700e80619ceb73235ca88e23e377514e00 ⤷ d8afdda07a5b6edfa7d8ccdad6d055f927843f1c 📝 The following sources have been considered for the creation of the settings: ⤷ Config file: /usr/share/voa/arch.yaml ⤷ Built-in defaults</code></pre> After installing the voa-verifiers-arch</a> package, which provides the VOA verifiers used by Arch Linux, it is possible to verify Arch Linux artifacts (e.g. package files) using voa(1)</code></a>: $ voa verify arch package default openpgp /var/cache/pacman/pkg/shadow-4.18.0-1-x86_64.pkg.tar.zst{,.sig} ✅ /var/cache/pacman/pkg/shadow-4.18.0-1-x86_64.pkg.tar.zst.sig 1751009927 991f6e3f0765cf6295888586139b09da5bf0d338 62cc73f884e52957b2fdd8839b7a287d9a2ec608</code></pre>Web of Trust and the Berblom algorithm 🕸️</h3> The generalized "Web of Trust" model remains an interesting option in the OpenPGP domain. The "Web of Trust" enables more complex and more nuanced setups than the basic "trust anchor" mode. It also allows for fully decentralized management of trust, without relying on any single authority. Over the course of 2024 and 2025, research has gone into comparing different "Web of Trust" implementations (see wot-observatory</a>). The existing (legacy) implementations have surprising limitations and/or defects when it comes to the calculation of trust. This research led us to the conclusion that instead of relying on existing implementations and designs, a new approach was warranted to overcome the limitations of existing "Web of Trust" subsystems. Our design is highly modular and centers around a pathfinding algorithm named "Berblom"</a>. Berblom is a novel and well-documented approach, which serves as a robust, general and efficient way of calculating the trust amount for an artifact verifier. We are excited to integrate Berblom into the VOA reference implementation in 2026. Future work 🚀</h2> We believe the ALPM project</a> succeeded in the goals it set for itself in the funding</a> period with Sovereign Tech Fund</a>. While a lot of foundational documentation and central libraries have been written, there is still more work ahead. More lints 🧶🧶</h3> The new lint framework provided by alpm-lint</a> currently only features few lints. Going forward, we want to extend this list in the dedicated "Lints" milestone</a> and encourage anyone with Rust experience and an interest in packaging to help with this. In addition to implementing lint rules, we want to explore the inclusion of the alpm-lint(1)</code></a> CLI in the canonical package build tooling for Arch Linux. C-API 🇨</h3> Our original project plan included potentially emulating the libalpm</a> C-API in the scope of the contracting work. However, during the last months we realized, that for many consumers it would be more useful to rely on the finer grained libraries of the ALPM project</a> directly instead. In addition, not all relevant database handling features are fully implemented yet, which would limit the usefulness of a C wrapper library. In the medium term, it is certainly possible for interested developers to create an emulation of the libalpm</a> C library based on ALPM. Reach out in case you are interested in something like this! Repository database handling 📦️</h3> In the alpm-repo-db</a> crate we have added support for the data files in use in an alpm-repo-db(7)</a>. Going forward, we want to add full handling of the database format: Creation, reading and compression of alpm-repo-db(7)</a> files and the addition, update and removal of entries. Add libkrun support to rootless-run 🏃‍➡️</h3> Both fakeroot(1)</code></a> and rootlesskit</code> have their place in certain contexts, but they each also have their weaknesses (e.g. fakeroot(1)</code></a> does not provide isolation, rootlesskit</code> does not work in a containerized context). Going forward, we want to explore adding libkrun</a> support to rootless-run</a> to accommodate stronger isolation on the basis of KVM</a>. Downloading of artifacts ⏬️</h3> The alpm-package</a> and alpm-repo-db</a> crates provide integration for handling local package and repository database files. In a package management workflow these are usually downloaded from an alpm-repo(7)</a>. We want to provide support for securely downloading these artifacts over the network. Verification of artifacts 🔏</h3> VOA provides a distribution- and technology-agnostic specification for artifact verification. Using the voa project</a> reference implementation, we want to add OpenPGP based verification for alpm-package(7)</a> and alpm-repo-db(7)</a> files. More VOA technology backends 🔐</h3> With the technology backend for OpenPGP in place, we have ironed out the generic handling of verifiers in the voa reference implementation. Interested parties have already worked on a proof of concept for an x.509 technology backend</a> and provided a ticket for the inclusion of signify as technology backend (see voa#24</a>). If you are interested in helping with the specification and implementation of more technology backends, please reach out! Extend Python bindings 🐍🐍</h3> We are very happy with the current feature set of python-alpm</a>. Going forward, we want to extend the API for the Python bindings further to cover even more use-cases of interested projects, such as archinstall</a>. If you enjoy hacking on the intersection of Rust and Python, feel free to reach out! We would be excited to collaborate with any interested contributors. More applications ⌨️</h3> The new set of ALPM project</a> libraries enables building robust tools. Users of the libraries can rely on a strongly typed, memory safe language 🦀 This empowers developers to build new special purpose package management applications with much greater ease. We look forward to building such applications ourselves, as well as seeing other parties building them. Ultimately, user-facing improvements are our goal, and we think the foundation that we laid over the past year is fertile ground for innovation. Introducing pkgctl license 2025-08-02T00:00:00+00:00 In Arch Linux, as part of RFC40</a>, we have recently decided to license all Arch Linux package sources as 0BSD</a>. Our package sources didn't have any license previously. RFC40 only specified that we do want to license our package sources but it didn't specify how to ensure this. As such, in RFC52</a> we decided we want to use REUSE</a> to achieve that. NOTE: It might be a bit confusing that our PKGBUILD</a> files also have a license</code> field. However, this field specifies the upstream license, i.e. the license of the software that we package. It does not specify the license of the package sources. This blog post is about tooling to manage the licenses for our package sources. REUSE</h2> REUSE is a tool that checks whether all files in your project are legally accounted for. Without it, it wouldn't be quite so clear which files fall under what license exactly. REUSE requires either per-file SPDX-License-Identifier</code></a> annotations or a central REUSE.toml</code>. We decided we wanted a central place per repository for all licenses and went with having a REUSE.toml</code> file. That file has a fairly simple format and usually looks something like this: version = 1 [[annotations]] path = [ "foo.c", ] SPDX-FileCopyrightText = "John Doe" SPDX-License-Identifier = "GPL-3.0-only"</code></pre> So, that's our fundamental building block. The licenses should always be in the format specified by SPDX</a>. Before checking the licenses of a project that we have setup with a REUSE.toml</code>, we have to download the respective license files. This is achieved using reuse download --all</code>, which will download the specified licenses to the LICENSES/</code> directory. Afterwards we can run reuse lint</code> to check the project for license compliance. Integrating into devtools</h2> Most of our package maintainer tooling lives in the devtools</a> repository. The idea now was to integrate REUSE with our existing tooling to ease the pain with initial setup and to ensure that it's always run before our package maintainers push new packages. We have roughly 12000 packages and we wanted to save everyone's time as much as possible. Having our folks write 12000 REUSE.toml</code>s by hand wasn't going to cut it. Integrating into pkgctl</h3> We use pkgctl</code></a> as our universal swiss-army-knife for all kinds of packaging related tasks. It offers commands to conveniently interact with many relevant aspects of Arch Linux. As such, it only made sense to integrate the reuse</code> command with pkgctl</code> somehow. For this pkgctl license</code></a> was created with its two subcommands pkgctl license setup</code></a> and pkgctl license check</code></a>. There's now also an integration in our package commit process</a> ensuring that new package sources are committed with a valid REUSE setup from the start. pkgctl license setup</h3> This subcommand will try to generate a valid REUSE.toml</code> for the given package. At the time of writing, our default base REUSE.toml</code> looks like this: version = 1 [[annotations]] path = [ "PKGBUILD", "README.md", "keys/**", ".SRCINFO", ".nvchecker.toml", "*.install", "*.sysusers", "*sysusers.conf", "*.tmpfiles", "*tmpfiles.conf", "*.logrotate", "*.pam", "*.service", "*.socket", "*.timer", "*.desktop", "*.hook", ] SPDX-FileCopyrightText = "Arch Linux contributors" SPDX-License-Identifier = "0BSD"</code></pre> It will always work fine if the package has no patches. In case .patch</code> files were found, we assume they have the same license as the upstream software itself and we'll then generate something that looks like this: [[annotations]] path = [ "fix-something.patch", ] SPDX-FileCopyrightText = "upstream contributors" SPDX-License-Identifier = "MIT"</code></pre> This automatic generation will fail in case the package sources have multiple licenses and patches</a>. pkgctl license check</h3> This command checks whether we have a top-level LICENSE</code> file with our expected Arch Linux-specific 0BSD license and then runs reuse lint</code>. If this command is happy, we're happy. Simple enough. Common problems</h2> Automatic REUSE.toml</code> generation fails in some known cases. The most common cases are these: Non-standard Arch-specific package source files are included in the repo</h3> Sometimes, we have some auxiliary files that are not part of the default REUSE.toml</code> that we generate. This could be, for instance, some shell scripts that help with packaging. In this case, they should usually just be added in the annotations array for 0BSD</code> as they are most certainly created by package maintainers. Multiple licenses and patches</h3> In case the package has multiple licenses and there are patches in the repo, pkgctl license setup</code> can't automatically decide which of the licenses should be assigned to the patches. In that case, it will generate a dummy license annotation for the patches. This approach, as opposed to failing outright and refusing to generate any REUSE.toml</code>, was chosen so that our package maintainers would be able to just figure out the right license and put it in the SPDX-License-Identifier</code> line. This is less annoying than also having to write all the annotations by hand. In case there are problems with the REUSE.toml</code> or any of the files in the repository, running pkgctl license check</code> will fail and inform the package maintainer of any necessary manual intervention. PKGBUILD doesn't specify the license in SPDX compliant format</h3> In RFC16</a> we decided to use valid SPDX license identifiers</a> in the license</code> field of our package build scripts. However, to this day, many of our packages still specify the upstream license in a non-compliant format (e.g BSD</code> instead of BSD-3-Clause</code>). In that case, package maintainers need to figure out what the correct license identifier is, provide it in the license</code> field and then run pkgctl license setup -f</code>. Specifications 2025-07-23T17:00:00+00:00 In October 2024 a team of dedicated developers has started work on the ALPM project</a>. Since then it has been focusing on writing new documentation on many aspects of Arch Linux Package Management that were not thoroughly documented in the past. This article provides an overview of the specifications written by this project and attempts to contextualize them for the reader. The existing stack 📚</h2> With its bash</code></a> based makepkg</code></a> tool for package creation, the libalpm</a> C library for interfacing with system state and the central pacman</code></a> package management tool, the pacman project</a> has defined the foundation of package management on Arch Linux for the past 20 years. Over the years, several adjacent projects emerged, that provide functionality beyond the scope of the pacman project: namcap</code></a>: PKGBUILD</a> and package file linting.</li> dbscripts</a>: Binary package repository management used by Arch Linux to manage the official repositories.</li> devtools</a>: A set of scripts and configuration files that also encompass Arch Linux's canonical package build tool pkgctl</code></a> which wraps makepkg</code></a> and performs builds in clean chroot environments with the help of systemd-nspawn</code></a>.</li> </ul> Each Linux distribution has a similar stack of tools, that allows for the creation of package files from some form of input, the management of binary package repositories and the installation and management of those packages on end-user systems. However, many of these tools are not used by end-users, unless they themselves maintain their own package build scripts and binary package repositories. On distribution documentation 🔍</h2> The documentation of a distribution is key to its success, as it provides its members with access to details on tools, file formats and the overarching concepts. While Arch Linux's ArchWiki</a> is a great resource for using the distribution, it lacks detailed information on developing it, as well as the concepts governing the existing tech stack. Arguably, a wiki is not the best place for documentation of this sort, which is also made note of in RFC0021</a>: Documentation on the operational side of Arch Linux is better served in a separate, dedicated place. Similarly, central documentation on common file types, data types and concepts used in the package management stack are an important cornerstone for a shared and broad understanding of the technology. This helps package maintainers, application developers and end-users alike in collaborating and improving the existing set of tools. Falling through the cracks 🕳️</h2> The projects in the existing stack</a> document most of their own functionality and use-cases for end-users. However, when considering strict validation of artifacts between the various building blocks in the ecosystem, it became clear that large areas of these projects are underspecified and only loosely follow an overarching design. For example, APIs or file formats not considered public or important enough for a dedicated specification by one project may be integral to the safe use of another project consuming its output. The ALPM project</a> follows in a long tradition of tools in the Arch Linux package management ecosystem, while more strongly focusing on modularity and validation. Already early on it became clear that an extensive documentation effort would be needed as the foundation of its granular design. ALPM specifications 📜</h2> Based mainly on black-box tests with the existing tooling, as well as input from longtime package maintainers and developers, a growing set of specifications has been written by the ALPM project</a>. Currently, the documentation is split between information on file formats and concepts. Some specifications already exist in multiple versions, which document different revisions of a format that changed over the past years. For local access to all specifications in the form of man pages, install the alpm</code> package group. pacman -Su alpm</code></pre>Concepts 📝</h3> alpm</a>: A top-level overview of Arch Linux Package Management, from package creation to consumption.</li> alpm-package</a>: Specifies what ALPM-based packages look like and what they contain.</li> alpm-meta-package</a>: Explains what meta packages are and how they are created.</li> alpm-split-package</a>: Explains how split packages work and how they are created.</li> alpm-architecture</a>: The CPU architecture identifier used in file formats and file names.</li> alpm-comparison</a>: The comparison functionality of packages (in particular versions) in various file formats.</li> alpm-package-base</a>: The use of pkgbase</code> in the various file formats</a>.</li> alpm-package-group</a>: Explains how package groups work in the various file formats</a>.</li> alpm-package-name</a>: Specifies how package names are used in the various file formats</a> and package files.</li> alpm-package-relation</a>: The relationships between packages as used in the various file formats</a>.</li> alpm-package-source</a>: The types of package sources in use in PKGBUILD</a> and SRCINFO</a> files.</li> alpm-package-source-checksum</a>: The hash digests used for package sources in PKGBUILD</a> and SRCINFO</a> files.</li> alpm-package-version</a>: An overview of the different types of version strings in use in the various file formats</a>. More details on specific components of version strings can be found in alpm-epoch</a>, alpm-pkgver</a> and alpm-pkgrel</a>.</li> alpm-soname</a>: The handling of soname information in package relations in some of the available file formats</a>. This concept exists in multiple versions (alpm-sonamev1</a> and alpm-sonamev2</a>) and describes how soname information of ELF files is used in metadata.</li> alpm-state-repo</a>: A repository in which metadata about the state of one or more binary package repositories is maintained.</li> </ul> File formats 📄</h3> SRCINFO</a>: The format of .SRCINFO</code> files found in the package source repositories of all official packages as well as all AUR</a> source repositories. It provides metadata about the sources and packages defined in an enclosed PKGBUILD</a> file while not requiring Bash to access this data.</li> ALPM-MTREE</a>: The format of .MTREE</code> files found in all package files. This file format exists in multiple versions (ALPM-MTREEv1</a> and ALPM-MTREEv2</a>) and describes all files contained in a package file.</li> BUILDINFO</a>: The format of .BUILDINFO</code> files found in all package files. This file format exists in multiple versions (BUILDINFOv1</a> and BUILDINFOv2</a>) and describes the environment used to build a package file.</li> PKGINFO</a>: The format of .PKGINFO</code> files found in all package files. This file format exists in multiple versions (PKGINFOv1</a> and PKGINFOv2</a>) and describes the metadata of a package file.</li> alpm-install-scriptlet</a>: The format of an .INSTALL</code> file found in some package files. This script file is used to run custom commands around the installation, upgrade or uninstallation of a package.</li> alpm-repo-desc</a>: The format of desc</code> files found in repository sync databases. This file format exists in multiple versions (alpm-repo-descv1</a> and alpm-repo-descv2</a>) and describes the state of a single package in a binary package repository.</li> alpm-db-desc</a>: The format of desc</code> files found in local libalpm</a> databases. This file format exists in multiple versions (alpm-db-descv1</a> and alpm-db-descv2</a>) and describes the state of a single package on a given system.</li> alpm-db-files</a>: The format of files</code> files found in local libalpm</a> databases.</li> alpm-repo-files</a>: The format of files</code> files found in repository sync databases.</li> </ul> In the works 🚧</h3> Further specification documents are planned to describe repository sync databases and a new format for the handling of binary repository state in the future. The documents are usually accompanied by dedicated parser and writer implementations, which are validated against real data to ensure their correctness (or to find bugs in existing tooling and data). If this article sparked your interest, consider contributing to the ALPM project</a>!

Arch Linux Dev Blog

Verify Arch Linux artifacts using VOA/OpenPGP

Listing verifiers 👁️‍🗨️</h2> VOA specifies a hierarchical directory structure. For each type of artifact, a specific subset of this structure provides a set of "verifiers" that must be used for artifact verification.</p>

A year of work on the ALPM project

Python bindings 🐍</h2> We provide Python bindings to make our modern Rust-based parsers and verified types available for use in some other projects of the distribution.</p>

Introducing pkgctl license

Specifications