Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Beware, the binary .apk's have unreleased patches you can't get from compiling yourself.


On their Github page they say

> This code is up-to-date and is matching the build on the Play Store.

which seems to be in conflict with your statement.


How did they check and verify that?


Since there is no commit history I would also like to know which Chromium version this is based on, so that a diff can be made.


That sounds shady. Thank you for the warning. How does one determine that?

Also not found on F-droid. Hard pass.


F-Droid has the same potential tampering issue: apps there are signed by the F-Droid key, not the developer’s key.

An F-Droid compromise could backdoor every app.


Any history of this?

For anyone: Why don't they cross-sign with their key+dev key?


Because the builds are (generally) not reproducible


I think cross-signing implies adding a second signature (notarization) to an existing dev-signed build, not doing a rebuild.

Does apk support such a thing?


Check out Bromite, they have an F-Droid repo that you can add to F-Droid!

Not affiliated with Bromite, just cycling accounts, can point toward my last one if anyone's concerned about this acct's greenness.


You got my hopes up but Bromite doesn't support extensions according to their FAQ https://github.com/bromite/bromite/blob/master/FAQ.md


My chosen threat model does not allow for significantly less security in exchange for extensions.

Also, they may very well take PRs for extension support (haven't looked through their Issues/roadmap), but, I'm sure it's not on the top of a security-first project's to-do list.


Evidence




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: