[3.18] System change proposal: Rust in main

Summary

Presently, Alpine provides the rust programming language in the community repository.

However, this has resulted in many packages being migrated to community, that users and maintainers would prefer to keep in main, such as Ansible, and soon, Mesa. It is also expected that the Linux kernel may start to use Rust for some subsystems in the future.

A key reason why Alpine presently maintains Rust in the community repository is due to a lack of formal stability assurance from upstream. By taking the steps outlined in this SCP in concert with the implementation of suggested steps in the Rust community, it is believed that stability can be sufficiently guaranteed to warrant inclusion in main.

Thanks to @jirutka and others in the Alpine community for reviewing this proposal, as well as Esteban Kuber from the Rust Compiler development team.

Benefit to Alpine

It is assumed that by following the steps in this proposal that Alpine users will be presented with a functional Rust toolchain which has a maintenance window of 2 years, that is also supportable by the Rust community through its normal support channels.

Contingency Plan

If we are unable to meet the requirements of this proposal by the time 3.16 freeze approaches, Rust will remain in community until the 3.17 release.

Owners

@kaniini (on behalf of the security team), others TBA.

Requirements for adoption of rust in main

Support of rust in main is an ongoing burden, which will require creation of a dedicated Rust team (thereafter referred to as "Rust team"), like the base system toolchain team. It is desired that maintainers of Rust packages as well as participants in the upstream Rust development process participate in this team. We propose that the Rust team is chartered with an upstream contact serving as liaison between Alpine and the Rust core developers.

The Rust team must provide a production-quality Rust toolchain which passes all tests to be included in main. Updates to the toolchain must continue to pass tests. It is proposed to use Alpine's CI system to build Rust snapshots on a weekly basis against the Alpine patchset to verify that all tests pass. It is expected that the Rust team would coordinate with upstream as appropriate to solve any test failures. This will be implemented by maintaining the Alpine Rust patchset in git, in the same way as the GCC patch set is maintained.

The Rust team must provide this toolchain for all architectures supported by Alpine. A rust package must be able to be built with arch=all, unless there is a specific reason not to.

The Rust team must provide the latest stable release on all supported branches within a reasonable time period (no more than 14 days after upstream release). As the Minimum Supported Rust Version (MSRV) varies wildly from package to package, providing the latest stable release is key to ensuring that security updates to applications continue to build.

In the event of a CVE or other vulnerability against the base Rust toolchain, it is expected that Rust Upstream will give sufficient notice in order to allow the Rust team to prepare new packages within an accelerated time period. The Rust team is expected to abide by any embargo requirements imposed by Upstream.

Finally, it is expected that the Rust team produce a policy manual for the work-in-progress Developer's Handbook outlining best practices for packaging Rust software in Alpine.

Oxidation of components in the Alpine base system

With the introduction of Rust to the base system, it may be desirable to oxidize certain components which have high security value in the system. Such discussions will be postponed until at least Alpine 3.18 development cycle (late 2023) to allow for the Rust team to acclimatize to meeting the proposed obligations.