Portal:Aeon/DevelopmentThoughts

CSL: Community Support Levels

Aeon is based on TW but by design we only support a subset of the packages from Tumbleweed

That said, even though we discourage customising the base OS, we do want to enable contributors to evaluate new possible defaults for Aeon and give our users some freedom to tinker - but with the obvious caveat that they may be compromising the expected reliability of Aeon in the process.

And so, I'd like to propose a 3 tier "Community Support Level" system for evaluating an Aeon system and all the packages within

CSL 1 - This system is "fully supported Aeon", using only default packages/patterns. Any customisation will invalidate Aeon's CSL 1 standard

Bugs reported from CSL 1 systems should always receive priority as they're expected to affect all Aeon users.

CSL 2 - This system is "partially supported Aeon", using mainly default packages/patterns and extra RPM packages which are either 'known good' or 'unknown good'. This may include packages from known 3rd party repos (eg. NVIDIA). This will therefore probably be where Nvidia systems will end up, as well as systems where people customise the base system using a few random packages from TW.

Bugs reported from CSL 2 systems should still be fixed on a "best effort" basis, but at a lower priority than CSL 1. It should be expected that bugs from CSL 2 systems are more likely to be closed as WONTFIX if the package is too complex/not relevant to fix for Aeon. Such bugs are likely to lead to packages being added to the CSL 3 blacklist.

CSL 3 - This system is "unsupported Aeon", using packages which are 'known bad' and are actively blacklisted, possibly by using rpm conflicts in the Aeon product RPM. This would also include any packages from unknown 3rd party repositories. Any user installing such packages will therefore need to manually move from the "openSUSE Aeon" product to an "openSUSE Aeon - Unsupported" product to make it absolutely clear that they are not aligned with the direction of the communities travel. For example, installing YaST or KDE on an Aeon system will immediately classify that system as CSL 3.

Bugs reported from CSL 3 systems will be handled with the lowest priority, and should be expected to be closed as WONTFIX unless it's obvious the bug may also be relevant to CSL 1 or 2 systems.

If this idea is popular, we'll need to make some userspace tooling to evaluate the CSL status of a Aeon system, so it can be used in bug reported. This tooling would ideally also help systems transition from higher numbered CSL levels to lower number ones (ie. it should be easy for a CSL 2 system to be 'reset' to CSL 1 and remove any of the potentially unsupported Aeon customisations)

No FDE, Yes FHE

Full disk encryption, while obviously popular, doesn't actually make much sense in a Laptop/Desktop use case.

If the disk is encrypted with a passphrase, then every user of the Desktop needs to know that passphrase - which really undermines the Linux/Unix concept of being a multi-user system.

Alternatively, if the disk uses mechanisms like TPM to unlock itself, you're only protected if someone removes the hard drive from the system - which is highly unlikely in a Laptop scenario, where the Laptop is more likely to be stolen than the hard drive.

For these reasons, Aeon will not be supporting FDE in any way at all.

However, users need to have a secure Linux desktop, so we'll be using systemd-homed by default to ensure that every users home directory is securely encrypted. Not even root on a potentially exploited Aeon machine will be able to change a systemd-homed users encryption key.

This should also bring additional benefits including

• Support for FIDO2 as a second factor for user authentication
• User + Home directory portability, which is additionally useful in the event of resetting/reinstalling Aeon machines
• Forgetting encryption keys as system suspend, further improving security in a Laptop context

It does bring some complications

• Storage management will be slightly more complicated than ideal, as the encrypted loopback device will need to be allocated space and managed appropriately. homed will do much of that automatically, but even at it's best it doesn't scale wonderfully. However, given most laptops are realistically to be used by 1-5 people most, this shouldn't be an issue
• SSHing into an homed user will be much harder/impossible to support, as the user will need to be decrypted with the passphrase before SSH can read the key information. Given Aeon should be the OS you SSH FROM not SSH TO this is probably not the biggest issue
• Some tooling like gnome-initial-setup will need to be modified to work best with homed, which may cause some rougher edges than ideal for a while

aeon-check

Description

aeon-check analyses an installed Aeon system and evaluates a systems for any known issues and declares its Community Support Level (CSL). Stores its results in `~/.local/share/aeon-check`, as either `~/.local/share/aeon-check/results/basic` or `results/deep` depending on which command was run. reset will reset Aeon to resolve any issues identified by the last "deep" check. If there are no available "resetters" for the found issues, the user will be advised to reinstall Aeon.

Commands

• basic - (Default) performs basic checks as the currently run user
• deep - performs basic and more invasive checks, will run as sudo
• reset - performs "resets" based on the results last run "deep" check, will run as sudo.

aeon-check-container

Description

The aeon-check-container is a Tumbleweed based container that is pulled and executed by aeon-check. It must contain all the dependencies for acc and all of the tests/resetters. It is a separate container built as part of each Aeon product build. This will therefore be able to contain the pristine package lists from the latest Aeon installation image, acting as a perfect reference point for various tests.

acc

Description

acc, or the "aeon-check-controller", which runs inside the aeon-check-container. acc manages the execution of "tests" and "resetters"

• tests are scripts/applications to check for potential known issues in Aeon, such as unsupported changes to the packages installed
• resetters are scripts/applications to resolve those issues in Aeon, such as resetting the packages installed to a pristine golden list

Tests are stored in `/usr/lib/aeon-check/tests/basic` and `/usr/lib/aeon-check/tests/deep`. "basic" tests must be executable as an unprivileged user and will be run as the user which calls aeon-check. "deep" tests will be run as sudo/root and so can run more invasive checks like the `btrfs` command to ensure sub-volume properties are correct. Tests should be named `$NUM_$TESTNAME", with `$NUM` being used to control the order the tests are executed in. Tests can be written in any language, and must finish with exit code 0 to pass. Any other exit code is considered a failure.

Resetters are stored in `/usr/lib/aeon-check/resetters/basic` and `/usr/lib/aeon-check/resetters/deep`. Resetters should be named to match the test they would resolve. eg. a test called `basic/10_pkglist` which checks the package list of an installed Aeon machine would have a resetter named `basic/10_pkglist`. They are always executed as sudo/root, in a single transactional-update session which requires the Aeon machine to be rebooted to take effect