Ah, lol, no my question was genuine - as in, who is checking the app signatures, the /e/ team or the cleanapk team. I’d feel better if the /e/ team were doing it.

On a separate note, your screen shot shows hypatia successfully checked md5 hashes, but mine always fails to find the md5 database. Do I need to also selected large database in settings?

1 Like

39 posts and we arrived at no answer! :slight_smile:


I use the default databases and have not adjusted. :+1:

I currently use F-Droid (with a few added repositories) and Aurora (for a couple apps Sandboxed using Shelter) only. But yes agreed, it would be nice if team /e/ was verifying themselves, that seems to be a large task.

My bad on misinterpreting your original post, sorry. I now see my error. :man_facepalming:

To further explain App Store performs some sanity checks here based on information received from cleanapk. It verifies shasum for google apps and pgp signature for fdroid apps. Apps store cannot directly verify signature of google apps because there is no reliable service which can provide this info so it relies on cleanapk. We are trying to improve this process though.
Also as mentioned previously if there is a better option of an application store which caters to all users - those who want FOSS only and those who want apps they used on stock ROM’s then we will be more than glad to use it. Off course it would still require a lot of customization of code to adapt it to work seamlessly on /e/OS.

1 Like

Perhaps /e/ could host their own application store along the same lines as Cleanapk. At least we know who owns and runs /e/. Or, as a major user of cleanapk’s API’s, /e/ could ask Cleanapk to be more open and transparent about who they are.

I’m relatively happy that the apks from Cleanapk, that /e/ serves up via Apps, are safe and haven’t been tampered with (I’ve not heard of any problems with them), but I really don’t like doing business with organisations that try to hide their ownership and/or location. It makes me wonder what else they have to hide.

/e/ cant do that because it is illegal, you can’t redistribute as stated in Gooles tos So i think they are lucky they have found cleanapk :wink:

If it’s illegal for /e/ to do it then surely it’s illegal for cleanapk too? So /e/ won’t break the (unspecified) law, but they’re happy to use an anonymous company that will break the (unspecified) law. Not a lot if difference that I can see.

I think there will be a big difference in court if you are the owner or the client.

I think
Gogol and cleanapk relation may depends on U.S. reglementation,
Cleanapk and /e/ relation may depends on E.U. reglementation.

But we don’t know who the owner of is. It might be /e/ as a corporation, it might be someone connected with /e/ in a personal capacity, it might be Google, it might be the Tooth Fairy :slight_smile:

In any case, I still don’t know what is illegal about what cleanapk are doing. You quoted Google Play’s Terms of Service, but if we believe their solitary web page, cleanapk aren’t getting the apks from Google, so Google’s ToS are irrelevant.

What laws are cleanapk actually breaking? If they aren’t breaking any, then there’s no reason why /e/ shouldn’t openly follow their model, or buy them, or make them an offer they can’t refuse :wink: . If cleanapk are breaking some laws, then I would have thought that, by using the cleanapk API’s (which they definitely do - you can see it in the source code) /e/ are also in a dodgy position legally.

I have my own theories about who owns and/or controls, but I think that /e/ should be open and transparent about it (assuming /e/ know: if they really don’t know, then they really shouldn’t be using Until they are open about it, then it will continue to be a distraction from the great things that /e/ is doing, and may put potential users off using /e/ at all.

Anyway, I really should get back to testing v0.18 ROMs :slight_smile:

1 Like

See my comment above

I can answer one of your questions

How do I know the apks haven’t been tampered with?

The signing certificate per appid is not allowed to change over the appids lifetime (if a private key is compromised, publishers have to republish under a new appid). As new Apk installs are trust-on-first-use, if the package was signed by the proper certificate you have authenticity assurance for the lifetime of the install and later updates. Packages themselves have an integrity mechanism that is signed by the certificate.

How to deduct the Apk is signed by the original publisher certificate? there is no public notary (yet), but I speculate cleanapk does check this certificate fingerprint against prior fingerprints of the same package name. If they are identical as recorded (for month or years for historical known packages) cleanapk themselves have assurance too of uploading an Apk as intended by the publisher. Obviously an apk mirror can’t do this for never-before-seen appids. If you have a Play console developer account you should be able to query the Google Publisher API and get some datapoints from “upstream”.

I think similar to what Hypatia does for known-bad package cert fingerprints it would heighten assurance if a database of known-good appid:certfingerprint is preseeded on the device and pinning to the appids cert fingerprint on install.

Marlinspike of Signal created a community effort in 2011 for SSL certificates as alternative to CAs / Web PKI, “convergence” (defunct since a few years). It queried multiple notaries for their view on the websites SSL cert fingerprints to establish a quorum. If you get malicious certificates, a majority disagrees and warns. Something akin I envision for apk packages, then the apk mirror source is less of a concern on TOFU.

I wrote [HOWTO] verify Apk signatures and reflect on Publisher trust if anyone want to read more on it. There are websites recording historical certificate fingerprints, they offer their database to researchers or offer their services (androidobservatory (not active anymore), scatterscam (close to exodus-privacy), pithus).


You talk a lot on signatures and certificates. What about signature spoofing for microg on e? Weaker security, yes?

What about signature spoofing for microg on e?

I can see your concern and never reasoned about if on package install mayFakeSignature() is hit. Will test this on the weekend if a malicious package by barely having the fake sig perm in its manifest can supply arbitrary signatures at install time - it’s possible, while I think at install time without yet having granted the permission it should not be possible.

That said, I think /e/ should integrate mayFakeSignature() like Calyx did, narrowing down the possibility to two package names and using a constant for the spoofed signature. Too, also offering a devoptions switch to disable fake sig spoofing (Add Signature Spoofing toggle (enable/disable) in /e/. (#1302) · Issues · e / Backlog · GitLab) could settle concerns.

1 Like

/e/ is built with signature spoofing restricted to so that only system apps can do it. So, if you trust the /e/ system apps (and I don’t know of any reason not to, since their source is freely available), the security isn’t very much weaker

1 Like

How many developers review source for e’s fork apps and in app store?

System apps: Apps store app installing apps from unknown identity clean apk website, with “more than 60.000 apps”? Proprietary closed source maps app? Email app receiving attachments from anyone, with no virus scanning? PDF Viewer with Network permission? /e/ product description - a pro-privacy Android ROM and online services

Is this fine print inspiring trust: “Please note that /e/ does not support nor endorse any of the Apps, it just facilitates downloading and installing publicly available apps.” ? /e/OS Application Checker - e Foundation - deGoogled unGoogled smartphone operating systems and online services - your data is your data

“If you trust the /e/ system apps” is a giant leap for one person. 18+ default apps forked from original developers, so only e staff and associates are maintaining and securing the changes.

If you run e, and your identity is stolen, and you lose your savings and credit rating, who can you sue?

1 Like

If you don’t trust /e/ and its developers, then better to use some other ROM

If that is a serious concern for you, then better to not use any smartphone, or any device connected to the internet


Or use a different ROM whose developer does not hide behind shady fine print or make it easy to install apps from questionable sources.