If you are interested in an update, we now create an artifact via a reusable workflow:
And then attest that artifact with a separate org-wide reusable workflow in a different repo:
Called from
And
So the build signer URI will always be https://github.com/privacyguides/.github/.github/workflows/sign-artifact.yml@5c41b37a937aab5e50262f3ab672fc9b9438dbf9.
You can now submit new apps elsewhere: Sign in - Codeberg.org
cc @anonymous549 @anonymous595 @The_Learner @Grapeg @simon.farson675
For some reason there are a bunch of apps like google photos below with this |- which seems to break when you import the database to appverifier.
- package: com.google.android.apps.photos
signature:
- fingerprint: |-
3D:7A:12:23:01:9A:A3:9D:9E:A0:E3:43:6A:B7:C0:89:6B:FB:4F:B6:79:F4:DE:5F:E7:C2:3F:32:6C:8F:99:4A
5A:AD:2B:EE:6D:B9:5D:17:E0:5A:08:D7:D1:E6:4C:10:A1:51:18:79:15:44:83:91:6B:6A:E6:C7:FD:9C:B0:C6
sources:
- name: Google Play
issue: GH-221
apk:
sha256: 959c9839cf1767adb4d2929fcd77c9830816a2713ee498644904ec29268bb394
For comparison a working app goes straight fingerprint:blah:blah:
- package: dev.imranr.obtainium
signature:
- fingerprint: B3:53:60:1F:6A:1D:5F:D6:60:3A:E2:F5:0B:E8:0C:F3:01:36:7B:86:B6:AB:8B:1F:66:24:3D:A9:6C:D5:73:62
sources:
- name: AppVerifier
issue: GH-858
- name: Direct APK Link
issue: GH-1118
apk:
sha256: 25419574125636f09130027b08e431973efba6d384521abae0f57818d448320a
link: https://github.com/ImranR98/Obtainium/releases/download/v1.4.3/app-arm64-v8a-release.apk
- name: F-Droid (IzzyOnDroid)
issue: GH-858
apk:
sha256: 25419574125636f09130027b08e431973efba6d384521abae0f57818d448320a
another example: [New]: Air France ¡ Issue #956 ¡ privacyguides/verified-apps ¡ GitHub
For some reason it got added with the |-
How are you doing so?
This is in fact how Google Photosâ signature is found in AppVerifier, and pasting the multiline entry we have should verify it.
com.google.android.apps.photos
3D:7A:12:23:01:9A:A3:9D:9E:A0:E3:43:6A:B7:C0:89:6B:FB:4F:B6:79:F4:DE:5F:E7:C2:3F:32:6C:8F:99:4A
5A:AD:2B:EE:6D:B9:5D:17:E0:5A:08:D7:D1:E6:4C:10:A1:51:18:79:15:44:83:91:6B:6A:E6:C7:FD:9C:B0:C6
What it is currently: - fingerprint: |-DE:C7:34:29:CE:25:63:27:5F:5E:D1:98:25:E4:46:52:B3:2B:36:3A:46:F3:8B:DF:F9:AD:6D:CD:E4:84:2D:88
It should be:
- fingerprint: DE:C7:34:29:CE:25:63:27:5F:5E:D1:98:25:E4:46:52:B3:2B:36:3A:46:F3:8B:DF:F9:AD:6D:CD:E4:84:2D:88
If you keep that odd character in there it doesnât verify if you import. It says: user no match stored hashes: |-
The current app hashes do not match the user database entry
Maybe itâs not a problem if it works in the internal database idk
I donât follow what you are asking for.
Are you copying from Verified Apps â AppVerifier Database where it is pre-formatted into what AppVerifier expects from clipboard verifications?
I downloaded the data.yml file and imported it to appverifier-bg. I think because of that odd character in 28 of the entries, it breaks the user verification.
I guess I am asking to mass remove all of those characters and stop them from being added in the future. I donât really know I am just seeing the symptoms.
I see. This would have to be a problem for @RoundSalmon4 to solve if they want to. We do not intend for people to directly import the database file into various apps, so we canât change it on our end to work with AppVerifierBG.
We could maybe automatically generate a file in the format AppVerifierBG expects, but AppVerifierBG already grabs our database by default, so there is not really a reason to also import them to the user database FWIW.
Well it already works for all the entries except the few that have that format so idk.
Thanks for pinging me @jonah 
@Expert4870 out of curiosity, are you importing data.yml directly into the app? The Privacy Guides database is already included as part of the internal database, so there shouldnât be a need to import it manually.
That being said, the import issue with |- is a real bug â the parser doesnât handle fingerprints that use this YAML block scalar format. Iâve implemented a fix for the next release.
In testing I was able to import data.yml with no issues after the fix. Feel free to either ping me here or open an issue on GitHub (that will probably get a quicker response 
) if the issue perists.
3 posts were split to a new topic: âVerified Appsâ app for Android pre-release
What process are yâall using to verify app submissions? Sorry if I missed that part of the thread.
You can read through the Automated Checks and Verification Process sections on their GitHub or Codeberg.
https://github.com/privacyguides/verified-apps#verification-process:~:text=Verification%20Process
Usually at minimum we want to see:
So this way we have 2 data points minimum, which is why we donât just scrape the app stores alone.
If we are verifying manual APK downloads or custom F-Droid repos then there is some additional manual work to find out whether those download sources are legit. And if the app isnât available in stores at all then it usually isnât being added at this time.
I am also working on a way for app developers to share an even higher level of verification but this is a work in progress and we have not really reached out to any developers to adopt it besides one tester yet:
Hi Jonah
Is this also including github only releases/versions? I have Ente Locker installed from the ente github, which is has its own unique signing information that I have submitted. But itâs been bounced back twice to me on codeberg.
