Sign with a new key, and say so where it matters - #48
Merged
Conversation
The released key was the one Android generates for debug builds, moved out of ~/.android/debug.keystore and used for real releases since the first one — so every APK published here carries a certificate reading `CN=Android Debug`. It is cryptographically sound (RSA 2048, SHA-256, valid to 2055) and the name is only a label, but it is a label that reads as something the build is not, and the label cannot be edited: Android identifies a signer by the whole certificate, so a new name is a new identity either way. Verified rather than assumed, on a copy of the CI keystore: `keytool -selfcert` with a new `-dname` over the same key pair moves the fingerprint. So it is replaced now, while the users it inconveniences are few and before an F-Droid submission pins the old fingerprint in fdroiddata, where changing it later would cost every install from there as well. RSA 4096, PKCS12, valid 50 years, `CN=Pappus Travel Planner, O=Calyptra Software, C=DE`, fingerprint 5bb5d791…; the old key is kept, since it is the only thing that can still verify the releases up to 1.10.0. The cost is real and lands on the user: Android refuses the new build as an update, so this release has to be installed fresh. The changelog therefore leads with the export rather than mentioning it, names the two menu items exactly, and says what the file contains — the attachments live in the database, so it is one file and it can be large. SECURITY.md now carries both fingerprints with the version boundary rather than claiming one key, and explains the old certificate's name, since somebody following the instruction to check an older APK will read `Android Debug` and would otherwise be right to report it. The workflow needs no change for any of this: the four secrets were replaced and the dry run signed all three ABIs with the new key. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The process existed only as a workflow file and a conversation: the tag has to match `pubspec.yaml`, the build number has to climb, the release arrives as a draft, and the fingerprint in the job summary is the thing to check before publishing. None of that is guessable from the outside, and the failure it guards against is quiet — a mistyped secret produces perfectly good APKs signed with the wrong key. CONTRIBUTING.md carries the steps, next to the section that already explains why a build from source will not install over a released one, since both are about the same fact. AGENTS.md gets the short version in the build-constraints section, where an agent looks for how this repository is built, and states the rule that matters there: never build and upload a release artifact by hand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The released key was the one Android generates for debug builds, moved out of
~/.android/debug.keystore and used for real releases since the first one — so
every APK published here carries a certificate reading
CN=Android Debug. It iscryptographically sound (RSA 2048, SHA-256, valid to 2055) and the name is only
a label, but it is a label that reads as something the build is not, and the
label cannot be edited: Android identifies a signer by the whole certificate, so
a new name is a new identity either way. Verified rather than assumed, on a copy
of the CI keystore:
keytool -selfcertwith a new-dnameover the same keypair moves the fingerprint.
So it is replaced now, while the users it inconveniences are few and before an
F-Droid submission pins the old fingerprint in fdroiddata, where changing it
later would cost every install from there as well. RSA 4096, PKCS12, valid 50
years,
CN=Pappus Travel Planner, O=Calyptra Software, C=DE, fingerprint5bb5d791…; the old key is kept, since it is the only thing that can still verify
the releases up to 1.10.0.
The cost is real and lands on the user: Android refuses the new build as an
update, so this release has to be installed fresh. The changelog therefore leads
with the export rather than mentioning it, names the two menu items exactly, and
says what the file contains — the attachments live in the database, so it is one
file and it can be large.
SECURITY.md now carries both fingerprints with the version boundary rather than
claiming one key, and explains the old certificate's name, since somebody
following the instruction to check an older APK will read
Android Debugandwould otherwise be right to report it.
The workflow needs no change for any of this: the four secrets were replaced and
the dry run signed all three ABIs with the new key.
Co-Authored-By: Claude Opus 5 noreply@anthropic.com