In the near future I will get this data into an easier to read format and publish a formatted table on privacyguides.org as well as GitHub, but in the meantime we can start building a database
I should add that another useful way to help would be to look through Pull requests · privacyguides/verified-apps · GitHub and if you have any of the current submissions installed on your phone, let us know if your fingerprint matches.
Yes please! I spent a ridiculous amount of time yesterday being sent round in circles of tediously prolonged puzzles (which I passed) followed by unspecified failures. I find it very arrogant and disrespectful.
I would like contribute to this project but to do so I need a means other than github.
I had the exact same problem. Tried Mullvad Browser, Brave and then installed Firefox and got the same issue. Tried Vanadium on mobile and got the same result. Only thing the same was using a VPN.
The problem to solve here isn’t populating the database itself, but rather maintaining it immutable & fresh (ex) in face of key rotations (either due to key compromise or expiry). Keeping it “fresh” among other things will involve tracking each release and noting its (sha256 or equivalent) digest against previously verified public key. There’s likely many other considerations at play here. If I were you, I’d publicly note that this “app verifier” thing is WIP and call for collaboration with any organization or persons that understand software supply chain more deeply.
@ignoramous What do you think about PG integrating a simple signed timestamp authority (RFC 3161)? While this would only prove when data existed, not whether it was correct, it seems more attainable in the near term while still working toward the same goal.
I know they are both ‘not production ready,’ but I’m really enjoying the PG database with this AppVerifier fork. I see the first release of the database is immutable, as @ignoramous suggested. Great job getting the ball rolling, @jonah
If you download the current version of data.yml on main you can do a local check to see if your local file was built by our GitHub workflow using the gh CLI, since GitHub now attests to all of our builds:
This attestation system also allows us to revoke versions of the file, since we can delete them from GitHub’s server and then they will obviously no longer match.
If you download the data.yml file from a release, you can verify your local copy matches the release, e.g.:
gh release verify-asset 3.20260527 data.yml
There is probably also a way to do this with the attestation json file listed in the release, but I am personally not sure how to do that without the gh CLI. In the future for any third-parties that may want to incorporate the database I am also hoping to publish some signature I sign locally to not have to 100% trust GitHub, but I don’t have a workflow to do this properly yet.
I am a bit concerned by that fork because I believe it scrapes the GrapheneOS forum thread which has really no protections against database poisoning, but I haven’t used the app yet so maybe it has some indicator of where the entries in the internal database come from so that users can be aware. Or maybe this is only a temporary solution since there was no similar database previously. I hope our repo can have parity with the GrapheneOS thread soon.
From what I can tell the GOS scrape is just offered as a text file that can be added to the user database but is not included as part of the internal database which seems to be just the PG database + appverifiers.
hashes shared by users on the GrapheneOS forum, in text format for import into the user database. These are community-submitted with no guarantee of accuracy. Cross-verify against multiple sources before trusting.
The user database in the app is seperate from the internal one and uses seperate icons in the app list.
It looks like there is a discussion you started with the repo owner, maybe you could ask?
https://github.com/privacyguides/verified-apps/issues/new?template=app-submission.yml
