DivestOS EOL

Since the hard “over and out” cut (source) of Divest OS it was unclear if and how AXP.OS will continue.

State: 2025-02-27

Tasks

Main challenges which need to be solved (not ordered):

critical

• automating CVE kernel patcher [1]
• automating the ASB patching process [2]
• Webview replacement / automating Mulch patching [4]
  • F-Droid release (undecided if)
• Creating a Slim variant targeting Divest OS users (see #35) [5]

not critical

• Hypatia (not directly AXP.OS related) [3]
  • creating a forked hypatia app
  • automating signature db updates (90% done)
  • F-Droid release (undecided)

Progress details

[1] CVE kernel patcher

The kernel patching is essential for an ongoing enhanced security. This part has been checked quickly and it seems to be solvable. Automation is the key though and it already has been started to work on that topic. From what is known currently it should be possible to achieve continuing this part and even automate all or whole parts at least. As the process has just been started with it is unclear what challenges are behind the next corner though. Even though the process of patching itself IS release critical the January build will not contain any new Kernel patches to not delay releases even more. While the process is still ongoing we are close :)

UPDATE: 2025-02-20

I guess (i.e. hope) that I can finish soon the work on the CVE patcher. its code had to be adapted and also the build automation routines had to be changed at several places.

all the main changes have been done but there’s still/just some fine tuning left.

it all took longer than thought (isn’t that always the case..?!) but I had to walk deep through the code plus a lot of trial & error to get used to the process and fixing issues.

during wrapping my mind around all the required steps (with great help by Tad! thanks again dude..) I found that I cannot provide the exact content as Tad did. at least not without help.

for this you need to understand the process:

1. automatic fetch cve patches from some sources (e.g. CIP, Ubuntu, kernel.org)
2. partly manual: download incremental patches (increases a minor kernel version step-by-step, e.g. v4.9.200 -> v4.9.201)
3. manual review them
4. manual merge them with a global list of patches
5. manual test-apply them on some devices
6. manual re-do the same with several other sources which are not downloaded automatically
7. manual maybe even modify/extend patches to get them applied

the first part has been integrated in the automation process (1 and 2) and enhanced where possible.

the second part has been fully automated. this is useful for still maintained LTS kernel versions and the most ideal way to get patches included.

especially the last 2 parts are something I cannot provide (alone) and so will not make it into AXP.OS for now. but what we get are the Android patches (if they can be applied - which usually means on newer kernels only) plus the part which I can (almost) fully automate (CIP).

CIP (https://gitlab.com/cip-project/cip-kernel/cip-kernel-sec.git) has the advantage that we get backported patches from kernel.org to (LTS) supported kernels which increases the chance it can be applied on even older kernels, too.

so even though a lot more can be done manually we get at least the major sources included. The kernel patches Google releases usually (often/always?) have made it already in the CIP content (sometimes this happens long time before!). From all I found the now missing parts are reducing the result slightly only - from now on at least. The reason for this is that a lot of major manual work has been done in the past already (thx to Tad!) and upcoming manual picks are hopefully rare (while they will happen, ofc).

If someone is interested for taken the manual parts - let me know. actually it is about all the sources not mentioned above.

during the code review and integration into the automation process I found also general problems when applying patches:

if a patch did not apply (even though a pre-flight check said it should) the process continued. that means it is a) hard to track that during a build and b) if a patch fails during the git am/apply process it MIGHT would have worked using the fuzzy patch command. worst case: if 10 patches of 400 not applied you THINK they are while they weren’t. this has been enhanced in a way that if applying a patch fails it will try the patch command after. this does not just increasing the chance that it applies but it now aborts the build process if that happens so there is no chance this stays undetected.

the patch count was wrong, too bc if a patch passed the pre-flight check it was counted even when the Fix_CVE_Patcher script outcommented it in the next step. this has been fixed as well and a re-count of the real to be applied patches happens after outcommenting.

Kernel patches have been applied successfully up to 2025-02-19 on a first test device! Next step is doing clean builds and tests with all other devices asap.

TL;DR: we will get CVE kernel patches with the February builds but in a (slightly) reduced manner.

UPDATE: 2025-02-21

so.. there was still not just fine tuning left it seems. anyways but now the previously used workarounds which ensured proper patch handling have been moved to the cve patcher directly, i.e. it will write the correct patch lines including:

• fallback to patch cmd
• when fallback applies it will parse the patch and grab its metadata (author,date,subject)
• and applies the patch with that metadata + a link to the git repo pointing to the origin patch

Also the patch count is now 100% accurate! instead of counting those which might apply (Divest) and instead of counting which should apply (see UPDATE: 2025-02-20) we now count (cve_checker v0.8.3 or later) the REAL amount of successfully applied(!) patches. nothing more, nothing less.

Some patches for Dec 2024 and January 2025 were not properly downloaded in one of the previous attempts so they have been re-imported.

I started to deprecate the use of git submodules within the main build repo already while they are still there to ensure nothing breaks during the current work on the CVE kernel patcher. Especially for the kernel patches this makes no sense anymore and these have been moved to the manifest instead.

The automation had to be adapted again as well to reflect the changes above.

[2] ASB patching process

The ASB patching process has been adapted and implemented via Ansible.

[3] Hypatia

Hypatia has been forked already, a server has been setup, ci/cd building of the apk works and half of the dozens of signature sources have been automated to fetch and convert for hypatia. Atm it is unclear how the project will be named and when it will been released officially though. In any case it is planned to make it available via F-Droid. There is also an attempt to maintain it here.

[4] Webview replacement

Webview has been forked and is available already.

[5] Divest-like flavor

The (so-called) Slim flavor was requested by several users which should not contain root or Google Play and provide a Divest-like experience. The issue tracker has been updated to ask users which variant the request is made for (defaults to the Pro flavor). So if you came here as a Divest user and want such build feel free to open a FR and select the SLIM flavor there. Read more about these AOS flavors here.