Fork of Mulch Browser?

DeletedUser60

I was wondering if someone know of Forks for Mulch Browser? Because I only know of IronFox which is a Mull Fork...

DeletedUser67

DeletedUser60 I asked the Maintainer of IronFox if he can maintain Mulch too and he told me that he has a lot to do but he will ask some of his Developer Friends if they could maintain Mulch. Let's wait and see. He will tell me if they will take it up.

AlphaElwedritsch

Not yet

GrapheneOS

We already have Vanadium, which is where Mulch was getting the patches from in the first place.

DeletedUser67

GrapheneOS I think that he was asking for Users outside of GrapheneOS.

MentalM

GrapheneOS I see now that IronFox is available in the Accrescent app list. What would be the use case to choose that over, or next to Vanadium on a GOS device? As I understand it, the mozilla project FireFox (and likely the forks then as well...?) have a larger attack surface: is this then reduced by IronFox?

Xtreix

DeletedUser67 We don't know unless OP makes it clear. However, I also don't see the point of using it on GOS when we already have Vanadium unless you just want to compare them. It should be noted that Vanadium will probably be available outside GrapheneOS., but it won't benefit from a full hardening, so it won't be exactly the same.

SovereignCopper

MentalM

Here are some:

Block known fingerprinting and ads via uBlock Origin (plus all the other perks of it)
(Try to) prevent fingerprintability done by unknown/unblocked entities via further mitigations
Proxied use of Google's safebrowsing
Removes or disables telemetry, experiments and other Mozilla stuff not needed for browsing

As for as continuation of Mulch, FWIW the developer of AXP.OS (a continuation of DivestOS) has put the releases of their browser based on Mulch here: https://codeberg.org/AXP-OS_releases/app_aosmium/releases

GrapheneOS

MentalM Firefox-based browsers have drastically weaker protection against exploitation than Chromium, especially on Android where they don't implement sandboxing yet. There's an even bigger gap when comparing to Vanadium.

Dumdum

MentalM What would be the use case to choose that over, or next to Vanadium on a GOS device?

Pretty much just extensions/better adblocking I think. Vanadium (and Chromium in general) doesn't allow extensions on Android, and adblocking is currently much more basic in Vanadium than something like uBO.

GrapheneOS

SovereignCopper Using a very niche browser makes fingerprinting easier, not harder.

As for as continuation of Mulch, FWIW the developer of AXP.OS (a continuation of DivestOS)

It was based on forking the DivestOS code but it's not really a continuation of it. It doesn't follow the same approach.

SovereignCopper

GrapheneOS Which is why Vanadium would also benefit from wider availability. This would also eliminate the need for Mulch-like initiatives.

GrapheneOS It was based on forking the DivestOS code but it's not really a continuation of it. It doesn't follow the same approach.

Their SLIM variants do to a large extent.

GrapheneOS Step in the right direction: IronFox has enabled fission by default.

TheGodfather

SovereignCopper Step in the right direction: IronFox has enabled fission by default.

It nevertheless does not use isolatedProcess, so it won't really matter.

GrapheneOS

SovereignCopper

Their SLIM variants do to a large extent.

Not really, and we already posted about our thoughts on whether it would make sense to continue DivestOS as is:

https://grapheneos.social/@GrapheneOS/113772409415058393

ceramics

SovereignCopper Which is why Vanadium would also benefit from wider availability. This would also eliminate the need for Mulch-like initiatives.

I'd invest greatly in Vanadium. Make it as close as possible to solving many browser issues, make it available in play store (if there's no compromise), increasing user base, market it like a gateway drug to GrapheneOS.

steadfasterX

GrapheneOS

What means "not really"?

AXP.OS Slim is based on DivestOS:

using the same build env and setup as DivestOS
using the same build scripts as DivestOS
using the same patches as DivestOS

AXP.OS Slim is also using the same build(!) config as DivestOS with the following exceptions:

it includes AuroraStore
adds different F-Droid repos which are all disabled by default (except the AXP.OS stable one which is used to provide out-of-band updates)
it allows WiFi calls
it uses a more restricted microG implementation
instead of the deprecated Mulch it includes the AOSmium WebView based on the same patch set as DivestOS did

The idea of that Slim flavor is exactly that, continuing the DivestOS spirit and that's why it is almost identical built. Of course AXP.OS uses different automation methods for actually building but all the rest ... I continued even the cve kernel patcher, Mulch, Hypatia, and so on and so forth.

The Pro flavor is a complete different approach and target group obviously.

missing-root

ceramics the GrapheneOS camera already kinda is

Watermelon

steadfasterX I would personally never trust any software you publish to be secure. I don't think you're doing it out of malice, but you seem to have an extreme lack of care for security. Your username (steadfasterX) matches the username of the person on Android File Host and XDA forums who publishes mAid (formerly FWUL which used to be published on AFH, I remembered your username from AFH). Your last version of mAid, version 4.2, which you should've retracted 1 year and 6 months ago, is still publicly downloadable and contains malware (CVE-2024-3094, XZ Utils backdoor). Now that you've been notified of this, please retract this version immediately.

steadfasterX

Watermelon

Oh wow. Thanks for the hate. We discussed about AXP.OS Slim and you.. (Trying to) blame me and that without any proof and then taking this to say I am not taking security any serious. Loving that.

Ok so, first things first: mAid 4.2 is not affected by that CVE. Sorry but you are wrong.

Pls read: https://archlinux.org/news/the-xz-package-has-been-backdoored/ (especially the top part of it (!) and the last topic "Regarding sshd authentication bypass/code execution")
The Manjaro discussion: https://forum.manjaro.org/t/xz-package-contains-a-vulnerability/159028/27

Besides all that, mAid 4.2 was built on 30th of March where the xz pkg in question has been replaced already (version 5.6.0 still though but without that code).
You can even check the virustotal results for the binary in question of mAid 4.2 (https://www.virustotal.com/gui/file/caf351bfe51bb4e0fe822bd4ffab580f50ceb6e82c5706d40f5ef0a5af1b971a/detection)

Watermelon

steadfasterX mAid 4.2 was built on 30th of March

That's not what it says:
The mAid homepage (that I linked to earlier) says:

mAid v4.2
Release date: 2024-03-15
MD5sums:
full: 2b626b46131ba60626e10873c42fe9e9
light: 23aa315de202ca190ac9b00ab66b226e

The changelog linked from the homepage says:

mAid_v4.2_x86-64
Released: 2024-03-15

And the SourceForge download link from the homepage says:

mAid_v4.2-full_x86_64.iso
Modified: 2024-03-15
Size: 2.6 GB
SHA1: a3820ae7450058ffed06f6967399839b03f04448
MD5: 2b626b46131ba60626e10873c42fe9e9

All of them say March 15, not March 30.

steadfasterX Ok so, first things first: mAid 4.2 is not affected by that CVE. Sorry but you are wrong.

Pls read: https://archlinux.org/news/the-xz-package-has-been-backdoored/ (especially the top part of it (!) and the last topic "Regarding sshd authentication bypass/code execution")

The Manjaro discussion: https://forum.manjaro.org/t/xz-package-contains-a-vulnerability/159028/27

Actually I did look for the Arch Linux news post after sending my post here. I'm not sure what to think. Should I feel safe that it's the compromised version but the attackers supposedly didn't inject malicious code into the Arch Linux build? Besides this, I don't care about the specifics of the behavior of the malware.

steadfasterX You can even check the virustotal results for the binary in question of mAid 4.2

Antivirus scanning is not an authoritative source to determine whether something is safe so I don't particularly care about these scan results.

steadfasterX Oh wow. Thanks for the hate. We discussed about AXP.OS Slim and you.. (Trying to) blame me and that without any proof and then taking this to say I am not taking security any serious. Loving that.

I also saw that the Pro flavor of AXP.OS is “pre-rooted” with support for “re-locking” the bootloader as if that would achieve verified boot. And AXP.OS has the stated purpose of being a balance between security, privacy, and usability, but the Pro flavor throws this balance out of the window by having zero security and privacy. And you still use MD5 in 2025 (not talking about SourceForge).

I probably wouldn't have noticed you if I hadn't used mAid/FWUL, so at least I found it useful, and I know another person who found it useful, so thanks for that at least. And as I said, I don't think you're doing it out of malice. But you don't come across to me as someone who cares about security. Sorry

de0u

Watermelon I would prefer a discussion more focused on technical matters (e.g., MD5 in 2025?!) versus allegations about what people do/don't "care about".

steadfasterX

Watermelon

sorry I was in rush when searching for the release date via my phone. the rest remains true though. keep in mind that the target group and goal for mAid is a complete different one than for AXP.OS. I never said the mAid live ISO is a high security daily driver while I still implement features like Secure Boot etc. yes, sha256 and sha512 are only shown on sourceforge which is the main download page though. but yes, hash sums on the homepage and for the release is something I have to fix though.
I haven't updated mAid since a year as it is really just a "small" personal project and again for a complete different target. speaking of that, the reason for the long release pause is that I publish releases after being completely tested only (which is a lot of effort) and for this I need enough free time doing so. since that time I had put much more time into AXP.OS which increased even more after the EOL of DivestOS. For AXP.OS it is way more important being current, tested and stable as I it is in use by some ppl as their daily driver. and I take that very serious.

supposedly didn't inject

no supposing here, it is 100% clear that the malicious code has no effect in mAid. well as long as you can read code and trust git at all. a new mAid release is in the works btw besides the nightlies which can be used in the meantime regardless.

Antivirus scanning is not an authoritative source to determine whether something is safe so I don't particularly care about these scan results

I didn't say it's an authoritative source for determining whether something is safe, but not including it would be unwise. I am pretty sure you would link that source if they would show "90% infected". It is ofc just one tool in a set of tools and also methods when analyzing stuff like that, so if you want to do that seriously you should care about malware scan results, imho.

[...] support for “re-locking” the bootloader as if that would achieve verified boot.

I have no idea what makes you think that. re-locking the bootloader and verified boot are different things and if there is something not clear on the website let me know. as before with your first post it seems you didn't took the time reading first and instead just throw out what you feel (which is OK if you would explicitly mark it like that).

You can read about the bootloader re-lock and also what it is meant for here: https://axpos.org/docs/guides/installation/bootloaderlock/

the other topic regarding verified boot: many devices for AXP.OS do support verified boot and which ones are clearly mentioned at their info and download page. (e.g. h815 does not while Fairphone4 does). This is regardless if that is the Pro or Slim flavor.

again, my statement you replied on first was explicitly about AXP.OS Slim but anyways.

the Pro flavor throws this balance out of the window by having zero security and privacy

"zero security and privacy". I think (again) it seems you are not happy with my person in particular and then out of this feeling claiming statements like that. AXP.OS Pro and Slim both using DivestOS deblobbing tools (and extending these) to remove a lot of calling-home calls ((I am not aware about another project doing that in this scale since Divest's EOL), it patches all devices with monthly (that changes as we all know) ASB patches, uses GrapheneOS' hardened malloc for most devices, includes a Vanadium based WebView and also applies CVE patches on all kernels (I am also not aware about another project doing that last one in this scale, GrapheneOS aside ofc).

The goal of AXP.OS Slim is identical as it was with DivestOS: taking back (some) control of your device. AXP.OS is meant mainly for devices which are not getting support anymore, i.e. end-of-life devices and even devices not supported by LineageOS or GrapheneOS anymore. AXP.OS is not a second GrapheneOS or CalyxOS, but it brings back life to devices which were otherwise kept in the drawer forever. it is clearly stated that for best security you should use a modern (Pixel) phone and switch to GrapheneOS

And you still use MD5 in 2025 (not talking about SourceForge).

sorry wrong again. AXP.OS has no single MD5 hashsum, for simplicity the unstable ones:

https://leech.binbash.rocks:8008/axp-unstable/
(you can go through https://leech.binbash.rocks:8008/axp as well)

where do you see md5sums? I mean yes the special recovery files for ODIN which is the Samsung flashable format but it does not support other hash algos for these devices. these are convenient files but users can download the regular recovery image + the sha256 file for it and create their own one if they want.

besides that all sha512 sum files are GPG signed (e.g. https://leech.binbash.rocks:8008/axp-unstable/AXP.OS-22.2-20250815-dos-sunfish.zip.sha512sum) which will be added for the sha256 ones soon, too.

besides that build notifications get sent to the notification channel (containing its sha256sum).

Besides that every build can be verified by the OTA signature and its build ids.

as you likely have seen on the linked page, AXP.OS also increases key size + hash (8192 / sha512) for AVB, APK signing and dm-verity (incl. adjustments in recovery and OTA Updater to support higher hash algo).

But you don't come across to me as someone who cares about security

that is OK. you do not trust me because you feel like that and I am not here to change this because my personal feeling here is that it does not matter what I say you will dig around until you find something where you can say again sentences again like: "I would personally never trust any software you publish to be secure" and "you seem to have an extreme lack of care for security" or "having zero security and privacy" ... which is just .. wow.. and I'm really trying not to take it personally. :)

anyways I am always open to suggestions and am aware that neither I nor my projects are perfect!
I cherish my privacy and am passionate about security, but ultimately, I am only human and do my best to be of help to others.