Submit Android apps to our AppVerifier database

Announcements
21

caught red-handed :joy:

9 Likes
22

OMG! I just submitted 16 apps before I realized my github account is shadowbanned. fuck. all my issues didn’t get created what a scam :sob:

my github account (404 on your end, works on my end)

image
image1830×1194 243 KB

1 Like
23

Oh no :sob:

Can you still access them?

1 Like
24

Yes.

1 Like
25

I could easily copy the markdown

1 Like
26

I got shadowbanned a while back too. Apparently it was because I changed my email to a simplelogin alias.

2 Likes
27

Okay I copied the markdown for each issue, so it would be easy for anyone to make the 16 issues.

You just have to copy between the titles of the apps for the issue contents and the title for the title. If someone wants to make these into issues. You just use a blank issue and it will easily format them.

Markdown paste.to

Markdwon might be harder to copy paste

this one seems to format it as well, but if you click edit you should be able to get the raw markdwon unformatted

1 Like
28

Thanks, I will do it myself quick. Sorry it didn’t work. I’m hoping to have another way to submit in the future, but the workflows are pretty GitHub-centric since we are relying a lot on formatted issues and automated checks for now, not manual PRs. I’m also associating each entry with a GitHub issue so that people can inspect them for more details, so I can’t use issue trackers on other platforms at the moment.

2 Likes
29

tbh, haven’t come across that RFC before today… I should probably read it.

There’s likely many ways to achieve whatever is the end goal, but I think using existing software supply chain tools & standards is more prudent.

The entries.

More pointers: Trillian lets you add tamper checking to a package manager | Trillian

Note that, the PG team doesn’t have to roll out the whole gamut of those standards; it may be worth the time to see if it can collab / get help to cherry-pick the necessary parts.

Since GitHub is a compliant implementation, any of the 3p SLSA (build track) verifiers would work here.

For build attestations? GitHub is great! Move the build attestation step to another workflow, and the build output would meet SLSA Level 3 (the highest level). For one of the FOSS projects I co-maintain, ref this commit on how we did so.

1 Like
30

I think the workflow we will end up having is self-hosting a copy of data.yml on a privacyguides.org domain, and then recommending people download it from us and verify that download against GitHub with the gh commands above. The end goals on our end would be two sources of truth (us & GitHub) and revocable releases of the data.

There is also a Level 4, FWIW. Looking at SLSA • Requirements I think we could meet the source/build/provenance requirements for 3 (not 4) with releases, thanks for the note :+1:

3 Likes
31

@jonah Thank you.

1 Like
32

Obviously temporary, but a searchable copy/pastable version is now available here:

8 Likes
33

I vote against github too.

I cannot even sign up. Infinite catcha loop.

Can you please consider GitLab or Codeberg? It have all the same automatisations and even F-Droid use them

4 Likes
35

You’re looking at a “draft” specification. Later, this was split into 2 tracks: Build and Source.

That said, I remember the discussions at the time that L4 (for the Build track) would mandate hermetic and/or reproducible builds.

That said, @RoyalOughtness seems to have a better grasp of supply chain security than most here.

1 Like
36

Oops. Well in any case we can meet L3 for either one. Also probably L4 for builds if it ever exists. It is not a serious build process, because it is literally just a file. We will have to do it for the built website as well eventually, but that will not be a challenge.

I mean just to be clear here, we are not talking about building a fork of an Android app or anything like that at the moment. We only want an immutable ledger of past versions.

1 Like
37

Just a suggestion but I think it would be helpful to show the total number of unique packages as well as “entries”. I think it would be more relevant for people who want to understand what is “covered” (ie actual app coverage breadth) by data.yml

1 Like
38

There are not many apps with multiple entries, but yes I’ll change this.

1 Like
39

Yeah I realized that when i first wanted to make this comment (see my deleted post :sweat_smile: ) but I think as the database grows larger and there are more apps with multiple hashes (or apps that do weird things like WhatsApp) it will be helpful.

1 Like
40

@jonah In the source names section of the readme the link to AppVerifiers own internal database goes to a fork and not the real repo.

2 Likes
41
1 Like