[P2] remove the sideload fingerprint from assetlinks.json at store launch

Open Beginner friendly
#799 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
68/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
android, typescript
Domain
mobile, security

Research direction

Start with src/public/.well-known/assetlinks.json and review the related reminder in scripts/verify-assetlinks.ts, using _bmad-output/specs/spec-assetlinks-publish/ for context. At store launch, add the Play App Signing fingerprint, remove the sideload fingerprint, redeploy, and re-check with Google's Digital Asset Links tester.

Written by the indexing model from the issue text.

Description

src/public/.well-known/assetlinks.json currently lists ONE SHA-256 fingerprint, and it belongs to a sideload signing key on the owner's machine, not to Play App Signing. It was published so a test build could be installed on a phone before a Play Console record existed (see _bmad-output/specs/spec-assetlinks-publish/).

While it is listed, any app signed with that key is trusted by Android as a verified first-party app for verticopolis.com: no browser bar, no warning. That is acceptable while the key sits on one machine and is one line to undo, but it is not acceptable once the real app ships.

What to do, and when

At store launch, once Play App Signing is enrolled and the Play-provided certificate fingerprint is known:

  1. Add the Play App Signing fingerprint to sha256_cert_fingerprints.
  2. Delete the sideload fingerprint C1:D1:...:DA:A3 from the array.
  3. Redeploy, and re-check with Google's Digital Asset Links tester.

Also delete it immediately, without waiting for launch, if the sideload keystore is ever lost, copied, or leaked.

Why this needs a tracked issue

Nothing fails if it is left in. scripts/verify-assetlinks.ts enforces that at least one fingerprint is present, and is deliberately blind to whether a given one still belongs there, so the build stays green forever with the temporary key listed. The obligation lives only in prose. Whoever adds the Play fingerprint will open a file with two entries and get no signal about which one to remove, which is exactly the failure this issue exists to prevent.

The script's header carries a pointer to this row so the reminder sits in the file a maintainer actually opens.

Dominant language
TypeScript
Stars
5
Forks
1
No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from maniator/verticopolis

All issues in maniator/verticopolis

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.