Secure and Trustless/Trust Minimal Package Policy

[Patrick]

DM = distribution maintainer

@nurmagoz

The package is only going to be as secure and up-to-date as the upstream developers made it.

secure:
DMs can and do sometimes add:

• Mandatory access control
• systemd hardening (capabilities… some introduction found here: GitHub - alegrey91/systemd-service-hardening: Basic guide to harden systemd services)

@nurmagoz

There must be no interference or external involvement in adding or removing code from any package (no package maintainer, only to make the package work as is from the upstream).

This interference as you call it is an expression of values.

values:

Proprietary tyrant competitors and project values

I am not worried about this. Related wiki chapter: Freedom vs Tyrant Security Hypothetical user quote: Due to lack of <insert cool security feature> by proprietary tyrant, I switched from Debian/Kicksecure to Google Android/iOS. That user doesn’t exist or is a minority infeasible to chase. In any case, we obviously cannot directly compete with proprietary tyrant companies with billions of USD in funding. That’s mission impossible. We can only compete on values. Such values include (no…

Packing policy is based on the values of the distribution:
Purpose of Packaging

@nurmagoz

Issues like packages crashing on shutdown when clicking X or freezing on specific Y action, are common (because they are already in the distro passing freeze timeline without upstream fixes), and such bugs when occurs are unlikely to be addressed in a timely manner.

Rolling will have more issues constantly introduced. Debian stable has a purpose: It’s stable.

@nurmagoz

What we get from Debian is, at best, working software, but that doesn’t mean it’s secure, up-to-date, or even always stable.

@nurmagoz

A major security flaw in Debian and Debian-like philosophies is that if the upstream of a package fixes a security issue and pushes it to their users, Debian remains unaware of it and will not include the fix in their own package unless it is documented or assigned a CVE.

Needs to be contextualized.

Kicksecure, Whonix server running Debian stable / Kicksecure:
12 years at time of writing.

Website known hacked, defaced through server hacking: 0

affected by xz backdoor: no

Rolling distributions: affected by xz backdoor: yes.

Ticket:

Rolling vs. Stable release brainstorming

Detailed overview of the issues with stable and rolling release distributions: Stable vs Rolling Distributions - Security Analysis Kicksecure’s current development strategy for the most part has been to harden Debian as much as is practically possible. This seems to have been working well for the most part, but there are some worries about the safety of some of the rather outdated software that Debian provides us. In particular: Critical, extremely complicated software like Firefox ESR and Th…

Related:

Kicksecure Stable Version User Experience

(Wiki spam / forum spam does not count. Not based on hacking.)

@nurmagoz

Another issue is the complexity trust in the chain of delivery. The more people who can add, remove, or manipulate the code, the more trust becomes a concern. If the code goes from developer X to intermediary Y (or even more intermediaries) before reaching the user, then the user must trust not only X but also Y and anyone else in the chain. Moreover, X doesn’t know Y or their practices, so X must also trust Y not to tamper with the code before reaching the user. This design introduces unnecessary trust assumptions. Code must be delivered directly from X to the user.

again:
Purpose of Packaging

Example… Reproducible builds…

Do you want grub or any other package reproducible?

Take the patch, here example for grub:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787795

Here’s a “small” list of patches:
https://udd.debian.org/dev/bugs.cgi?release=any&patch=only&merged=ign&reproducible=1&sortby=id&sorto=asc&format=html#results

(There’s also a larger list of patches for reproducible builds.)

Either,

• A) non-reproducible and no patch, or
• B) reproducible and patched

Choose one.

Want both? Maybe. If the patch gets merged upstream.

Sure. That’s the plan.

But what when upstream is slow and/or patch change requests?

That’s the case for grub:
GRUB Slow Upstream

Meanwhile the choice is between A and B.

Don’t want any intermediaries? Use Linux From Scratch.

https://www.linuxfromscratch.org/

Too complicated? Use a Linux distribution.

Want both no intermediaries and easy? Unavailable.