A year of work on the ALPM project
In 2024 the Sovereign Tech Fund (STF) started funding work on the ALPM project, which provides a Rust-based framework for Arch Linux Package Management. Refer to the project's FAQ and mission statement to learn more about the relation to the tooling currently in use on Arch Linux.
The funding 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"
- "Basic OpenPGP verification of artifacts"
- "Rust library for handling of individual packages"
- "Python bindings for alpm-srcinfo"
- "Distribution-agnostic OpenPGP stack for the verification of distribution artifacts"
- "Rust library for system package management"
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 π
A lot of work has been done over the time of the STF funding. Below are a few statistics about the work done on the ALPM project.
$ 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
$ 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
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Specifications π
Already in July we reported on the state of the specifications on the devblog 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 or concepts. Meanwhile, the alpm(7) 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 itself, as well as make it much easier to experiment with new applications that are built on top of it.
Foundational libraries ποΈ
In the ALPM project 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 to gain a better understanding and overview of the available libraries and their dependencies.
The central alpm-types 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, central traits and utility functionality are made available to other libraries in the workspace.
After some consideration and research, we chose the winnow parser combinator library to create parsers for the various custom file formats. Shared functionality for parsers is made available in the alpm-parsers library.
Package management systems usually revolve around central dependency resolver functionality. With alpm-solve we have created a new approach to this for Arch Linux, which is based on the generic resolvo library.
Compression is an integral part of the packaging workflow. It ensures that an alpm-package(7) or alpm-repo-db(7) file can be transferred over the network as fast as possible by reducing its size. With the alpm-compress library we have implemented extensible (de)compression for these files.
To allow extraction of metadata and data files from an alpm-package(7) file, as well as (rudimentary) package creation, we have created the alpm-package 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) 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 library, which generically abstracts running commands "as root" with the help of different backends (e.g. fakeroot(1) and rootlesskit).
Libraries and command line interfaces π»οΈ
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) (i.e. SRCINFO(5), PKGBUILD(5)),
- those in an alpm-repo-db(7) (i.e. alpm-repo-desc(5) and alpm-repo-files(5)),
- those in an alpm-db(7) (i.e. ALPM-MTREE(5), alpm-db-desc(5) and alpm-db-files(5)) and
- those in an alpm-package(7) (i.e. ALPM-MTREE(5), BUILDINFO(5) and PKGINFO(5)).
The alpm-srcinfo crate provides a library and command line interface for the parsing, validation and creation of SRCINFO(5) files from PKGBUILD(5) scripts. Due to the dynamic nature of the PKGBUILD(5) scripts, the SRCINFO(5) format is surprisingly complex (both to create and to evaluate). The creation of SRCINFO(5) files from PKGBUILD(5) scripts is enabled via the alpm-pkgbuild-bridge project, the alpm-pkgbuild crate and a translation layer in alpm-srcinfo. We have created dedicated documentation for the aspects of parsing and providing its data from different contexts.
The alpm-buildinfo crate provides a library and command line interface for the parsing, validation and creation of BUILDINFO(5) files. This file format is contained in an alpm-package(7) and describes its build environment. In the context of reproducible builds it is used to recreate the build environment.
The alpm-mtree crate provides a library and command line interface that allows parsing, validation and creation of ALPM-MTREE(5) files.
This file format is a subset of the mtree(5) file format, provided by libarchive.
As it can be considered more of a meta language than a data format, we rely on bsdtar(1) to write that file format.
An ALPM-MTREE(5) file is contained in an alpm-package(7), as well as an entry of an alpm-db(7) 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 crate offers a library and command line interface for the parsing, validation and creation of PKGINFO(5) files. This file format is contained in an alpm-package(7) and describes all relevant metadata of a package (e.g. alpm-package-relation(7), alpm-package-name(7), alpm-package-version(7)).
Each system based on alpm(7) maintains its state using an alpm-db(7). This state encompasses information on each package:
- the contained files (see alpm-db-files(5))
- general metadata (see alpm-db-desc(5))
- a record that can be used to validate files of a package (see ALPM-MTREE(5))
With the alpm-db crate, it is possible to parse, validate and create the alpm-db-desc(5) and alpm-db-files(5) file formats. Additionally, we have worked on database access for the alpm-db(7) structure following the ACID characteristics.
Packages for compiled languages (e.g. C or C++) usually contain files in the Executable and Linkable Format (ELF). These files may expose soname information which may be used as alpm-package-relation(7) (see alpm-sonamev1(7) and alpm-sonamev2(7) for the two currently understood formats). With the alpm-soname crate we have focused on the handling and extraction of information for the more modern alpm-sonamev2(7) format as well as plain soname information. As a library and CLI, this crate offers easy access to this ELF data, which plays an important role in figuring out the run-time dependencies of packages.
Each alpm-repo(7) contains a set of alpm-package(7) files, digital signatures and a package repository database (see alpm-repo-db(7)). An alpm-repo-db(7) tracks information on particular, unique packages:
- the contained files (see alpm-repo-files(5))
- general metadata (see alpm-repo-desc(5))
Using the alpm-repo-db crate, it is possible to parse, validate and write alpm-repo-desc(5) and alpm-repo-files(5) 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) files.
Development integration π·
To test integration of our libraries against real world data, we have created the dev-scripts crate. It lives in the context of the ALPM project, 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)
- official binary package repositories
Currently, it is possible to verify
- SRCINFO(5) files in package source repositories of the official repositories and all of the AUR
- ALPM-MTREE(5), BUILDINFO(5) and PKGINFO(5) files in binary packages in the official repositories
- the OpenPGP signatures of all packages in the official repositories
- alpm-db-desc(5) and alpm-db-files(5) files in the entries of a local alpm-db
- alpm-repo-desc(5) and alpm-repo-files(5) files in the entries of the alpm-repo-db(7) files of the official repositories
Python bindings π
To make our modern Rust-based parsers and verified types available for use from in other languages used by the distribution, we provide Python bindings.
Arch Linux's largest Python-based project, with arguably also the largest user-base, is the AURweb, which powers the Arch User Repository (AUR). The web application deals with user input, e.g. via SRCINFO(5) files and currently relies on the native Python library python-srcinfo.
(As a sidenote: If you are a Python developer and interested in helping maintain a FastAPI 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 are available on PyPI as python-alpm. With them, we have focused on providing SRCINFO(5) support by relying on the alpm-srcinfo library and by proxy expose a lot of types from the alpm-types library as well.
The integration of the python-alpm library into the AURweb application is currently prepared (see aurweb!876).
If you are a Python developer and have specific needs for the integration of other libraries of the ALPM project, we would love to hear from you!
Linting π§Ά
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) scripts) can the resulting package files maintain a high quality standard.
Relying on the written specifications, foundational libraries, as well as libraries and command line interfaces 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 crate, a central library and command line interface has been created, that thoroughly documents its architecture and how to add new lint rules. 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/
Using the alpm-lint(1) CLI, package maintainers are enabled to validate various scopes relevant to packaging (e.g. contents of an alpm-source-repo(7) or an alpm-package(7) 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 π
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 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 framework and created a convenient integration for our purposes with the custom fluent-i18n crate.
Interested users can now start translating the project on weblate, following our dedicated contributing guidelines on localizations and translations: https://hosted.weblate.org/projects/alpm/
VOA π
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.
- 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.
- The keyring is stateful, and while its contents are populated by data from the package for archlinux-keyring, the entire mechanism requires a root-run agent service.
- 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)andrpm(8)over the last three years. Compatibility with other OpenPGP implementations is no longer guaranteed (see e.g. the ArchWiki article on GnuPG for details)
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).
This idea was discussed with a set of cross-distribution developers during Image-based Linux Summit 2024 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, 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" from All Systems Go! 2025.
UAPI specification βοΈ
In late 2024 we started work on a specification 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)" 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 β¨οΈ
In July 2025 we started work on the VOA project, as a reference implementation of the UAPI specification.
Here are some statistics about the project:
$ git shortlog --summary --numbered
190 David Runge
17 Heiko Schaefer
3 renovate
2 David Schaefer
$ 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
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
Central handling of the VOA hierarchy is implemented in the technology-independent voa-core 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 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 or domain name matches for OpenPGP User IDs.
- 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 IDs and trust anchors can be filtered using OpenPGP fingerprints. Additionally, the number of required individual certifications for User IDs on each artifact verifier can be specified.
- "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 IDs and trust anchors can be filtered using OpenPGP fingerprints. 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.
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.
- There is a set of packager certificates that each must have an OpenPGP User ID with an email that uses the "archlinux.org" domain and has three or more third-party certifications from trust anchors.
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 as verifiers into VOA hierarchies from different sources. The import supports OpenPGP certificates split into OpenPGP packets and the custom directory structure used by archlinux-keyring.
With the voa-config 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)) 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):
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
VOA high-level API and CLI π₯οΈ
In the voa crate we provide a high-level API for consumers of VOA and a command line interface.
With voa(1), it is possible to:
- Inspect technology backend configuration settings.
- Import OpenPGP certificates as VOA verifiers.
- List all VOA verifiers (by OS or specific context).
- Verify a file using a detached OpenPGP signature and suitable VOA verifiers.
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
After installing the voa-verifiers-arch 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):
$ 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
Web of Trust and the Berblom algorithm πΈοΈ
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). 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". 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 π
We believe the ALPM project succeeded in the goals it set for itself in the funding period with Sovereign Tech Fund.
While a lot of foundational documentation and central libraries have been written, there is still more work ahead.
More lints π§Άπ§Ά
The new lint framework provided by alpm-lint currently only features few lints.
Going forward, we want to extend this list in the dedicated "Lints" milestone 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) CLI in the canonical package build tooling for Arch Linux.
C-API π¨
Our original project plan included potentially emulating the libalpm 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 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 C library based on ALPM. Reach out in case you are interested in something like this!
Repository database handling π¦οΈ
In the alpm-repo-db crate we have added support for the data files in use in an alpm-repo-db(7).
Going forward, we want to add full handling of the database format: Creation, reading and compression of alpm-repo-db(7) files and the addition, update and removal of entries.
Add libkrun support to rootless-run πββ‘οΈ
Both fakeroot(1) and rootlesskit have their place in certain contexts, but they each also have their weaknesses (e.g. fakeroot(1) does not provide isolation, rootlesskit does not work in a containerized context).
Going forward, we want to explore adding libkrun support to rootless-run to accommodate stronger isolation on the basis of KVM.
Downloading of artifacts β¬οΈ
The alpm-package and alpm-repo-db 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). We want to provide support for securely downloading these artifacts over the network.
Verification of artifacts π
VOA provides a distribution- and technology-agnostic specification for artifact verification.
Using the voa project reference implementation, we want to add OpenPGP based verification for alpm-package(7) and alpm-repo-db(7) files.
More VOA technology backends π
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 and provided a ticket for the inclusion of signify as technology backend (see voa#24).
If you are interested in helping with the specification and implementation of more technology backends, please reach out!
Extend Python bindings ππ
We are very happy with the current feature set of python-alpm. 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.
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 β¨οΈ
The new set of ALPM project 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.