DivestOS: long term device support with enhanced privacy and security

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: Scripts/WebView_Update_Repo.sh · 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.

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”.