Secure and Trustless/Trust Minimal Package Policy

One cannot educate oneself based on news alone. News is all about sensational, exceptional, negative, and current events. In that case, one will lack the required foundational knowledge.

Medical analogy:
To be able to research and contribute to improved heart surgery procedures, one needs to be a heart surgeon (or other qualified medical researcher). For example, I am not active in this field, hence cannot talk with certainty, demand heart surgeons times making suggestions on how to change their procedures.

Back to Linux distribution maintenance / operation system development:
To be able to contribute to Linux distribution maintenance, one needs to be a Linux distribution maintainer.

The problem is, that Linux distribution maintainers are not particularly good at marketing, advertising their hard work. They’re not creating engaging texts, flashy graphics, arguments, memes and videos. Hence, their hard work goes easily unnoticed.

What do all Linux distributions no matter how different they are in common? They do packaging. (And there is any that does not, they’ll have scripts or other files which replace this purpose.)

Alright. So you’ll start with a source code folder such as the source code of grub2. Select files from grub2 source code folder:

asm-tests
build-aux
conf
config.h.in
configure
configure.ac
INSTALL
and so forth

But a different structure is required for the binary installable package:

* etc/grub.d/10_linux
* usr/bin/grub-install
* and so forth

How do you get from source package to binary installable package? Answer: packaging. Who provides the package? The distribution maintainer. Who distributes the package? The distribution.

Alternative? Linux From Scratch. Read upstream’s readme, manually install the dependency and follow the upstream’s instruction for compilation, installation - if available.

We want a console login. How to do that? The standard Open Source tool for that is getty. But getty even if compiled and lingering on the hard drive as perfectly compiled binary does nothing. It needs to be started. How to start it? The init system starts it. How does the init system start it?

The init system requires a configuration file.

  • systemd: a getty systemd unit file
  • SysVinit: a SysVinit uses service configuration files

Who provides the init system configuration file for getty? Upstream getty? No.

Then who else does the Linux distribution integration work? The distribution maintainer, the Linux distribution.

Refer to Debian Policy Manual — Debian Policy Manual v4.7.3.0 for other packaging tasks.

This process is an absolute necessity. There is no (universally accepted) standard (file structure, compile command, init system, compile options, …) that all upstream projects follow to completely avoid any necessity for packaging work. If there was a standard or convention, there would not be enough participating upstream’s to build a functional Linux distribution.

Unfortunately, all of this necessary packaging work allows for vulnerabilities and/or malicious backdoors to be injected.

There are certainly different opinions on how to package, what should, should not be done and other specifics. That’s why many different Linux base distributions exist. However, unfortunately it’s not possible to completely wipe away.

Multi-billion surveillance capitalism corporations with power to do that. Open Source Linux distributions do not have this power due to the organisational differences, which are documented here: Linux User Experience versus Commercial Operating Systems

That is an unfortunate Arch Linux incident. For context:

As established above, packaging is unavoidable. Packaging files (and packages) must either be trusted and/or audited (preferably).

This issue could not have been prevented by a “no packaging policy”. That option does not exist.

Similar to above.

Packaging will be imperfect, there can be issues, yes, but unavoidable.

If there was a suitable base distribution that does that is of a higher quality then that would be an option.

I haven’t seen any Linux distribution yet that doesn’t add patches. They may or may not patch more minimally and the policy on what is acceptable versus unacceptable is probably different but they do patch.

In any case, this is up to the base distribution.

And Kicksecure is a “patch” on top of Debian. (Security Operating System Comparison - Kicksecure vs Debian)

In that case, we won’t realistically would not reach reproducible builds. I decided on preferring patches + reproducible builds instead of patch-less and unreproducible builds.

In any case, bootstrapping a base distribution at this point is entirely unrealistic. We don’t have even remotely enough developers / funding to make that happen.

Kicksecure for the foreseeable future will remain a derivative of a base distribution.