DivestOS: long term device support with enhanced privacy and security

Maybe? Maybe not! Talking it up is of no use in practice. SkewedZeppeli get off your one’s high horse.


h815 LG G4 INTL | DivestOS 14.1 / 7.1.2 / Nougat / END OF LIFE

How many non working builds were created for this h815?

After classic installation method of divested-14.1-20220709-dos-h815 the system boots only up to the divest logo from dark background.

An automatic reboot repeats continuously = bootloop. The ROM is not usable.


By the way: The CustomROMs from the developer @SteadfasterX for the ‘h815’ with /e/OS-0.23-p and lineageos-18.1 lineage-18.1-20220523-h815 have worked for years until today including the previous versions.

@fossys

high horse
…h815 have worked for years until today…

I could just quote myself:

I appreciate the direct and to the point language (from SkewedZeppelin)

I could just quote film:

What we have here is a failure to communicate.

but I will try to be more clear and not as insulting as you are.

While I appreciate your testing, I think you may not understand “working” for a device in the same way, “successful” for a ROM project like this, or having integrity and standards, and sticking with them regardless, for people.

What you could ask is: What corners are cut, or what standards are sacrificed for that other ROM to boot? Is it relockable? Does it disable SELINUX?

You could also ask “how much would I need to donate for you to buy a (device here) and get it working by DivestOS standards?”

That’s just, like, my opinion, man.

Awesome logo!

That is cool!

What about making it a bit more like a racoon and a little less like a badger?

New take:

Mull - Head

3 Likes

Ooh! That both looks like a raccoon and more suitable for icon use too!

I love this one-man show. Android OS minimalist,transparent. Respects privacy as much as possible, as safe as possible. Developer S.Zeppelin seems to have an “allergy” to non-transparent companies:-) Thank you guys. May FOSS be with you !

Man, I respect other opinions, but I’m not interested in yours. Nonetheless:

My attempts to make donations to Tad have failed.

The new user would gladly and immediately support your work, but not with existing payment options via Stripe (bank card), Liberapay, Bitcoin, Monero. :arrow_heading_up:

My last offer to send SkewedZeppelin a donation in the form of a Xiaomi Mi A2 was wordlessly ignored for four days, after which I removed it. I’ve understanding for waywardness, but not for snootiness.

Feel free to @me, and I can provide the files if you are interested in using my icon :blush:

Edit: it is kind of sad to see Mull without an icon on F-Droid and eOS app store </3

@optimumpro

Hiya, welcome! :wave:

All DivestOS devices are signed with unique keypairs as generated by this script: Scripts/Generate_Signing_Keys.sh · master · DivestOS Mobile / DivestOS-Build · GitLab

Devices have had unique keys since 2019/09/13.
Devices have had non test-keys since 2015/11/20.

And builds are signed here: Scripts/Common/Functions.sh · master · DivestOS Mobile / DivestOS-Build · GitLab

Here are the verified boot enablement scripts: Scripts/Common/Enable_Verity.sh · master · DivestOS Mobile / DivestOS-Build · GitLab and Scripts/Common/Copy_Keys.sh · master · DivestOS Mobile / DivestOS-Build · GitLab

And the public verified boot hashes, usually shown on bootup: Verified Boot Hashes - DivestOS Mobile generated by Scripts/Generate_Verified_Boot_Hashes.sh · master · DivestOS Mobile / DivestOS-Build · GitLab

Also related the support files script: Scripts/Generate_Supporting_Files.sh · master · DivestOS Mobile / DivestOS-Build · GitLab

And the WebView script: Files · master · DivestOS Mobile / DivestOS-Build · GitLab

Because it may not be obvious, the WebView compile script: build-webview.sh · master · DivestOS Mobile / Mulch · GitLab

Feel free to use them per the license.

My original post was a mistake and that’s why I deleted it even before you responded.

Having said that, I agree with others who say you need to get off your high horse.

You took it upon yourself to appear in one of my threads on XDA with negative remarks about my rom and at the same time promoting your own (you’ve been deleted there). Hardly a good behavior.

About DivestOS: Your software cannot be qualified as an independent development. It is just a small layer on top of Lineage. A layer that for the most parts contains some hardening commits from GrapheneOS.

Unlike Graphene developers, you have no control over the base rom. For example, you must wait for Lineage to merge security patches and often they are late. You can’t control their features, you can’t control their code. You must wait for them to fix their mistakes. You can’t implement features etc etc.

So, if I were you, I’d stay away from your ‘sniding’ others and concentrate on your own development.

Best regards.

@optimumpro
I’m not here to argue.
My comment in your thread was in direct response to someone asking the difference between my OS and your OS.
Your OS is proprietary, it isn’t necessarily a negative in context as clearly shown by your active forum threads with many users.
Your OS does not make it clear what changes are actually made OR who made it originally if not you, that is something you can improve on.
You do actually do a good job pulling in -stable patches into your kernels which is nice! Seriously not enough projects do that.

you must wait for Lineage to merge security patches

I consistently push them out before they do?
See https://divestos.org/misc/a-dates.txt and Patch Counts - DivestOS Mobile

I have never encrypted my back up, nor have I ever used a password manager.

  1. I am thinking to encrypt all my files before uploading to mega. Is this the correct approach if I want privacy and security? I mean is there any weakness in this approach? I think it depends on the encryption I use, and the password, and they can see metadata, like file size, date of upload etc.
    And which should I use? on internet I see people saying i) use AES 128 as it is more than enough and is faster, ii) AES 256 is necessary even though it takes more time.

  2. I want an offline password manager for both linux and android. I have heard keepassxc for linux and keepassdx for android is good. Is this alright or are there better alternatives? And I am okay to back it up manually, so is it alright if I store the passwords on mega after encrypting?

Thank you!

Keepassxc/dx is a great solution i personally use them and sync the database between desktop and mobile using syncthing.
To encrypt files in case you can also use pgp.

2 Likes

I use passwordstore.
I stores the passwords in single pgp encrypted files and thus feels very “unixy” and future-proof. The Android client works very well and gets updates from time to time.

It sets up the folder of password files as a git repo and comes with good git integration. So using a git server as backup and central distribution is pretty much a no-brainer.

I can NOT really say anything about keepassdx. But my git server for my passwords is a private repo at github (yes, yes, yes. Go on and sue me). I discussed this beforehand with fellow software engineers and we all agreed that this is save. This is what the enryption was invented for. If everything in your keeypass fole is encrypted you should be fine just as well.

One minor note: if you are going to put your password file ANYWHERE outside your computer its best to treat it like it was completely public. As such you want it to still be protected in 10 or 20 years. We might see widespread quantum computers in that timeframe. And if we do your “good old RSA encypted” files will not be save anymore. So I don’t think it would be overkill to opt for so called “post-quantum” encrpytion (like Ed25519)

Yes. In the case of passwordstore there is a little information leak since you usually use urls of websites as file names. So theoretically “they” (in your case mega. In my case github) know that I have an account for the F-Droid forum . . . or pornhub. But my username and password are save and secret “out in the open and encrypted”.

Hi everyone, I’m running DOS 19.1 on FP3 after a flawless bootloader-relock.
I only just noticed that my WiFi security is set to WPA/WPA2 with no option to change the security setup from within the Android network settings. I set my router to WPA2/3 transition mode so the connection defaults to WPA2, yet I’m worried that in future connections with other networks a downgrade to WPA would be possible.
I recall having a working WPA3 setup a few months ago, yet I was running LineageOS 18.1 back then so
I’m not sure whether the issue is related to the switch to DivestOS per se, the upgrade from 18.1 to 19.1 (including different menu structures) or my specific network (haven’t gotten around to checking with many different networks). Resetting the WiFi connections on my phone or rebooting the router haven’t had any effect; my notebook has a stable WPA3 connection within the same network.
Has anybody had similar issues? Any suggestions?

@doktorbrausefrosch
In general I recommend against using mixed-mode WPA2/WPA3.
Make a distinct WPA2 and WPA3 SSID on your access point if possible.

Benefits are better knowledge that a connection to a given SSID is the encryption you expect, prevents sharing group keys with lesser encrypted devices, and I’ve also found improved compatibility.

While I’m here, I’ll leave a fun fact: only WPA3 and WPA2-EAP provide PFS.

@SkewedZeppelin
Mixed mode is the best my router OS can do (seems not to be supported by OpenWRT btw). So is there any way to switch to WPA3 from within DivestOS, or at least force WPA2 for all networks without leaving the WPA-option open? And any plausible explanation that I seemingly can’t choose the setup manually anymore (“Network details → Security” is greyed out)? Help is greatly appreciated, as always!

@doktorbrausefrosch

For the Android side you can explicitely choose the WPA if you choose “add hidden network”.

For the router side, OpenWrt does support this at least for SoftMAC. Perhaps you’re on an old version?
Screenshot from 2022-08-16 15-54-14

@SkewedZeppelin
Thanks again, manually re-adding it worked!
My OpenWRT comment was misleading, I meant to say that my hardware is not supported so I’m running the stock OS on my router.

Ed25519 is vulnerable to quantum computers.
Always use symmetric encryption for backups.