Critical Security Inquiry: Supply Chain Risks and Trust Verification (Post-XZ Utils)

[elytraVIII]

I am evaluating the security of GitHub Store and have concerns regarding the 'Trust Chain.' The XZ Utils backdoor proved that 'Open Source' does not mean 'Safe.'

As an app that automates the installation of third-party binaries, you are effectively a gatekeeper. I have three specific critical questions:

Automated Trust: Beyond a legal disclaimer, what technical hurdles exist to prevent an upstream attacker from using your platform to push a malicious update to your 48,000+ users?

Verification: Does the app implement Signature Verification? If a developer signs their APK or AppImage, does GitHub Store verify that signature before prompting for install?

Infrastructure Security: How do you protect your own GitHub Actions/Secrets? If your CI/CD is compromised, an attacker could backdoor the GitHub Store app itself, giving them access to every device your app is installed on.

A 'download at your own risk' disclaimer is standard, but given the scale of this project, what is the roadmap for moving toward a 'Zero Trust' architecture?

[rainxchzed]

Thank you for taking the time to review the project and for raising these concerns

I'll address your questions individually.

1. Automated Trust
   GitHub Store does not automatically push binaries to users. The app functions as a client that surfaces releases published on GitHub repositories. Installation always requires explicit user action and uses the system installer.

Currently, GitHub Store does not modify binaries or host its own builds. It only retrieves artifacts published by the upstream project. This means the primary trust boundary remains between the user and the upstream repository.

2. Verification
   GitHub Store intentionally avoids acting as a binary mirror or build system. It retrieves artifacts directly from upstream repositories (e.g., GitHub Releases), which minimizes the platform’s ability to alter binaries and keeps the trust relationship between users and upstream maintainers.

For APKs, GitHub Store relies on the Android package installer, which enforces APK signature validation during installation.

The current trust chain is:

Developer
↓
GitHub Release
↓
GitHub Store client (fetches artifact)
↓
Android Package Installer (verifies signature)
↓
User

3. Infrastructure / CI Security

The CI pipeline is primarily used to fetch repository metadata daily and update cached data used by the project. Secrets are stored using GitHub repository secrets and are not exposed to pull requests from forks.

The workflow runs on a scheduled basis and commits updated metadata back to the repository. These automation tokens are limited to repository-scoped permissions.

A compromise of this CI workflow would primarily affect the integrity of the cached metadata repository, not direct access to user devices or accounts.

User authentication in GitHub Store is handled through GitHub OAuth with minimal scopes, and the application does not have the ability to access or control user GitHub accounts.

That said, CI/CD supply-chain risks are real, and further hardening (such as stricter repository protections and improved verification around releases) is something I plan to continue improving.

[elytraVIII]

I’m not a Kotlin expert, so I can’t provide a PR, but I’d like to suggest these three 'low-code' security features to strengthen the trust chain:

Signature Pinning (TOFU): Save the SHA-256 fingerprint of an app on the first install and block updates if the signature changes. This stops 'swapped' binaries.

Remote Blocklist: Have the app fetch a small blocked_repos.json file on startup so you can remotely 'kill' distribution of known malware.

Provenance Badges: Highlight apps that use GitHub Artifact Attestations so users know the binary actually matches the source code.

These would significantly mitigate XZ like risks without requiring a total rewrite of the app.

[rainxchzed]

Thanks for the thoughtful suggestions — these are great ideas and align well with the direction I'd like to move the project in.

Features like signature pinning (TOFU), a remotely updateable blocklist, and clearer provenance signals would definitely strengthen the trust model and help mitigate supply-chain risks.

I'll take a closer look at these approaches and evaluate how they can be integrated into GitHub Store in a way that fits the current architecture. Improvements in this area are something I plan to continue iterating on in future releases.

Appreciate you taking the time to share these ideas.

[elytraVIII]

Thank you for the detailed response! I'm glad the suggestions align with your vision for the project. I'll leave this issue open so it can serve as a reference or a tracking point for those security milestones as you evaluate the architecture. Looking forward to the future releases!