bit settled the model on weblib-viewer#19: the builder signs an APK, and
this repo (fdroid-repo-ci) only distributes it. Reason: an APK can
reach a device via a git release and via F-Droid, and updates from either
route have to install over each other, which needs the same signature on
both -- so signing has to happen once, at the build. It also matches how
F-Droid's binary-repo mode actually works: fdroid update reads each APK's
existing signature and never creates one.
Right now sign-apk.sh's place in the README's "Using it" example reads
like a required step in the default pipeline, and nothing in the repo states
outright that this repo must never be handed an app signing key.
Changes
Take sign-apk.sh out of the default publish path shown in action.yml
and the README's "Using it" example. Keep the script -- a consumer whose
build genuinely produces an unsigned artifact still needs it -- but
document it explicitly as the exception, not the norm.
State as an explicit invariant, somewhere visible rather than buried,
that this repo is never handed an app signing key -- only the repo
index key, which signs the index rather than any app.
Make sure the README's description of the pipeline matches: builds
arrive already signed; this repo indexes and publishes them.
Also worth recording while touching this:
the index key is, for now, the same keystore as the APK key, but they are
expected to be split later -- config/secret names for the index key
should stay distinct from the APK key's even while both resolve to the
same secret today, so splitting later is a value change, not a refactor.
the repo index key must be generated as RSA 4096, never 2048 --
overriding F-Droid's own docs, which suggest 2048 for the repo key.
Does not touch publish.sh's ordering, its credential check, its
refuse-on-existing check, or next_version_code.py -- those are settled and
merged.
bit settled the model on weblib-viewer#19: the **builder** signs an APK, and
this repo (`fdroid-repo-ci`) only **distributes** it. Reason: an APK can
reach a device via a git release *and* via F-Droid, and updates from either
route have to install over each other, which needs the *same* signature on
both -- so signing has to happen once, at the build. It also matches how
F-Droid's binary-repo mode actually works: `fdroid update` reads each APK's
existing signature and never creates one.
Right now `sign-apk.sh`'s place in the README's "Using it" example reads
like a required step in the default pipeline, and nothing in the repo states
outright that this repo must never be handed an app signing key.
## Changes
1. Take `sign-apk.sh` out of the default publish path shown in `action.yml`
and the README's "Using it" example. Keep the script -- a consumer whose
build genuinely produces an unsigned artifact still needs it -- but
document it explicitly as the exception, not the norm.
2. State as an explicit invariant, somewhere visible rather than buried,
that this repo is never handed an *app* signing key -- only the **repo
index key**, which signs the index rather than any app.
3. Make sure the README's description of the pipeline matches: builds
arrive already signed; this repo indexes and publishes them.
Also worth recording while touching this:
- the index key is, for now, the same keystore as the APK key, but they are
expected to be split later -- config/secret *names* for the index key
should stay distinct from the APK key's even while both resolve to the
same secret today, so splitting later is a value change, not a refactor.
- the repo index key must be generated as **RSA 4096**, never 2048 --
overriding F-Droid's own docs, which suggest 2048 for the repo key.
Does not touch `publish.sh`'s ordering, its credential check, its
refuse-on-existing check, or `next_version_code.py` -- those are settled and
merged.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
bit settled the model on weblib-viewer#19: the builder signs an APK, and
this repo (
fdroid-repo-ci) only distributes it. Reason: an APK canreach a device via a git release and via F-Droid, and updates from either
route have to install over each other, which needs the same signature on
both -- so signing has to happen once, at the build. It also matches how
F-Droid's binary-repo mode actually works:
fdroid updatereads each APK'sexisting signature and never creates one.
Right now
sign-apk.sh's place in the README's "Using it" example readslike a required step in the default pipeline, and nothing in the repo states
outright that this repo must never be handed an app signing key.
Changes
sign-apk.shout of the default publish path shown inaction.ymland the README's "Using it" example. Keep the script -- a consumer whose
build genuinely produces an unsigned artifact still needs it -- but
document it explicitly as the exception, not the norm.
that this repo is never handed an app signing key -- only the repo
index key, which signs the index rather than any app.
arrive already signed; this repo indexes and publishes them.
Also worth recording while touching this:
expected to be split later -- config/secret names for the index key
should stay distinct from the APK key's even while both resolve to the
same secret today, so splitting later is a value change, not a refactor.
overriding F-Droid's own docs, which suggest 2048 for the repo key.
Does not touch
publish.sh's ordering, its credential check, itsrefuse-on-existing check, or
next_version_code.py-- those are settled andmerged.