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.
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.
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.
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.
But we don’t know who the owner of cleanapk.orgis. 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
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 . 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 cleanapk.org, 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 cleanapk.org). 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
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).
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.
/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
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? https://doc.e.foundation/what-s-e#e-default-applications