Weekly Status Report: 2019-06-23

Hello all!

This has been an exciting week for Adélie Linux. We have formally created an Infrastructure Team, responsible for managing our servers and network infrastructure. This will allow us to have a more holistic approach to tending to our server systems, and help ensure that administration is handled smoothly and cleanly. We have also added and updated many packages; read on for more about these developments.

Web Site

Top 5 referring sites to the Web site:

  • 110: DistroWatch
  • 62: Google
  • 35: Reddit
  • 28: Repology
  • 21: Ungleich blog

Top 5 pages accessed (and homepage):

  • 1089: /
  • 374: /about.html
  • 133: /announcements/
  • 82: /about-qa.html
  • 51: /team.html
  • 44: /contribute.html

APK Tools

Max Rees (sroracle@) has identified and fixed an important security bug in APK Tools that has been issued CVE-2019-12875.


A. Wilcox (awilfox@) updated the -mc patchset to 4.14.127, creating -mc14.


A. Wilcox (awilfox@):

  • Updated 20 Perl modules to their current versions.
  • Updated many packages to their current versions, including eudev, the Enchant spell check library, file system utilities, Git, OpenSSL, the Ruby programming language, the SASS web development package, Subversion, the VLC Media Player, Wacom tablet support, various KDE applications, and various X11 applications and drivers.
  • Updated the POWER8 and POWER9 kernel package to the newest patchset.
  • Updated the packaging for the Quaternion Matrix chat client.
  • Fixed security issues in the Expat XML library and the libarchive tar package.
  • Added experimental builds for the LMMS music creation package, and the Nim programming language. (Note: These packages are not yet available for Adélie Linux.)

Kiyoshi Aman (aerdan@):

  • Fix installation of various fonts so that they are usable in all applications.

Luis Ressel (aranea@):

  • Updated the nsd and Unbound DNS server packages.

Max Rees (sroracle@):

  • Fixed security issues in many packages, including APK Tools, Cairo, cURL, CVS, the FLAC codec, Lua, Python, the PostgreSQL database system, and the TIFF image library.

Molly Miller (sysvinit@):

  • Added the cbindgen package, a dependency of newer Firefox versions. This is also the very first Rust package for Adélie Linux!

Urgent security patch for all systems running Adélie Linux

A grave security vulnerability has been found in apk, the package manager used by Adélie Linux. The vulnerability allows any attacker on the same network as your computer run malicious code as the superuser, if you are not using HTTPS repositories in /etc/apk/repositories.

This should not affect any standard installation of Adélie Linux, as our mirrors force HTTPS and our default repositories file uses HTTPS. However, if you have added your own custom repositories, or replaced ‘https’ with ‘http’ for any reason, you are vulnerable. A patch has been released in apk-tools 2.10.1 and it is critical for you to update all of your Adélie Linux computers immediately. New ISO and root FS images for 1.0-BETA1 went live this morning UTC (around 11 hours ago).

This vulnerability was discovered in early September by Max Justicz. A patch was written on 5 September by Alpine Linux developers and released on 10 September; the vulnerability was disclosed publicly on 13 September. The Adélie Linux team was not notified of this vulnerability before the public disclosure. This vulnerability was disclosed independently to Adélie Linux by Luke Dashjr via the public disclosure by Max Justicz.

We are deeply troubled by the lack of responsible disclosure by Alpine Linux, and we are actively investigating steps we may take in the future to mitigate our continued reliance on Alpine.

Official statement on x86_64 architecture security flaws

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.

Our official stance on the Rust programming language

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.

In Conclusion

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.