Many of you that use x86_64 computers are likely concerned with the various security flaws that have been discovered in the silicon of virtually all 64-bit Intel CPUs this year. There have also been a few requests for packaging official microcode updates.
Unfortunately, the EULA required to install, use, and redistribute these microcode updates is non-free. Intel has ensured that providing these updates to you would cause us to violate US and European copyright and contract laws.
As further security flaws are inevitable due to the design of the x86_64 architecture, and we cannot legally provide you with the updates necessary to avoid these flaws, we highly recommend that our users invest in computers using different architectures, such as PowerPC or ARM. While the x86_64 architecture will continue to be a Tier 1 architecture for the foreseeable future, we can no longer guarantee user security or data integrity to users using x86_64 computers with Intel processors due to Intel’s restrictive licensing.
Editor’s note: The original version of this statement included the following statement:
Furthermore, Intel has added a stipulation in the EULA for their latest microcode update that renders their CPUs non-free, by forbidding any usage of software that they arbitrarily determine to fall under “benchmarking”. This includes tools such as hdparm. Intel has since removed this clause from their license; however, the microcode itself is still non-free and we cannot distribute it.
A few people have asked us about when the Rust programming language will be packaged for Adélie. The short answer is that the Rust programming language fails the requirement that it can be packaged on all tier 1 architectures, and additionally fails to meet our libre source requirements. These issues are not insurmountable, and I hope that Mozilla will continue to work with the community to find answers to them. A more detailed explanation follows.
Issue #1: Rust requires binary Rust to compile
Our guidelines strictly require that all packages must be built from source code, without the requirement to trust upstream binary packages. You can read a few papers on the reason for this; a good starting point is Countering “Trusting Trust” by Bruce Schneier. Put simply, a compiler binary may be malicious, and the only way to prove that it is not is to compile it with a separate compiler. Rust is implemented in Rust, and there is currently only one implementation of it: Mozilla’s. A community effort to create a second implementation is underway, but it is not yet sufficient and supports only x86_64 currently. There is no way to know right now that Mozilla’s binaries do not have malicious code embedded without an independent Rust compiler.
Issue #2: Architecture support
Our guidelines strictly require that all packages support all Tier 1 platforms to be built as a supported package. (Packages that don’t may be maintained by the community at a site like APK Fission.) Rust, as of the time of this writing, does not support any non-x86 architectures; as of 1.8 (the last time triplets were documented), the PowerPC musl platforms were not supported even for custom builds.
Issue #3: Cargo now requires Cargo
As described in issue #1, our guidelines strictly require that all packages must be built from source code. As of the latest release, Cargo now requires itself to build, which again requires us to trust an upstream binary package. With this specific package, it may be possible to bootstrap using an older version of Cargo that still supported source builds without itself. This has not been investigated yet as the other two issues are far more pressing.
We would truly enjoy the ability to provide the Rust environment to our users, and we hope that Mozilla will continue to improve Rust’s tooling to allow this. Until such a time, the security and integrity of our distribution is paramount. To preserve that security and integrity required to create a truly libre Linux distribution, we are required to delay any packaging efforts for Rust.