First, thanks for this project. I've read the source and it's clean and well-documented. I have no concerns about the code itself; every endpoint is a Google domain and there's no third-party dependency or telemetry.
My question is about the release pipeline rather than the code. As far as I can tell:
- The GitHub workflow (
update-source) only regenerates docs/apps.json; it doesn't build anything
Scripts/make-ipa.sh builds the IPA locally and it's attached to releases manually- The IPA is unsigned (SideStore re-signs it on device), so there's no developer signature to verify either
That means trusting the app currently means trusting that the .ipa in Releases was built from the published source, with no way to check. I did some static checks on the 0.3.6 binary (URLs, linked libraries, Info.plist, build metadata) and everything matched the source, but that's not something every user can do, and it's not proof against subtler modifications.
Would you consider any of the following?
- Building in CI from the tag: a GitHub Actions workflow (macOS runner) that builds the IPA and attaches it to the release, so the binary has provenance tied to the commit
- Publishing the SHA-256 of each release IPA, committed at the tag before the IPA is uploaded
- Even better: attaching the build log or a workflow-run link to each release
I've opened #17 with a concrete implementation of options 1 and 2: a release-ipa workflow that builds the unsigned IPA on GitHub's macOS runner from the exact commit a release tag points at, and attaches it together with its SHA-256 (clobbering any manually attached asset, so the release always carries the CI-built artifact). Every release then links the workflow run that produced it, and verification becomes "check the run built from the tag" instead of "trust the uploader's laptop".
This isn't an accusation, just asking how the source-to-binary trust gap is meant to be closed, since sideloaded apps skip App Store review entirely.
First, thanks for this project. I've read the source and it's clean and well-documented. I have no concerns about the code itself; every endpoint is a Google domain and there's no third-party dependency or telemetry.
My question is about the release pipeline rather than the code. As far as I can tell:
update-source) only regeneratesdocs/apps.json; it doesn't build anythingScripts/make-ipa.shbuilds the IPA locally and it's attached to releases manuallyThat means trusting the app currently means trusting that the
.ipain Releases was built from the published source, with no way to check. I did some static checks on the 0.3.6 binary (URLs, linked libraries, Info.plist, build metadata) and everything matched the source, but that's not something every user can do, and it's not proof against subtler modifications.Would you consider any of the following?
I've opened #17 with a concrete implementation of options 1 and 2: a
release-ipaworkflow that builds the unsigned IPA on GitHub's macOS runner from the exact commit a release tag points at, and attaches it together with its SHA-256 (clobbering any manually attached asset, so the release always carries the CI-built artifact). Every release then links the workflow run that produced it, and verification becomes "check the run built from the tag" instead of "trust the uploader's laptop".This isn't an accusation, just asking how the source-to-binary trust gap is meant to be closed, since sideloaded apps skip App Store review entirely.