Closed Bug 844223 Opened 13 years ago Closed 13 years ago

gecko-unsigned-unaligned.apk is now signed

Categories

(Release Engineering :: General, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: nalexander, Unassigned)

Details

My use case: I have a script that downloads latest/gecko-unsigned-unaligned.apk, signs it with a debug key, and aligns it. I am steering new contributors to the android-services codebase to this tool so that they don't need to build Fennec themselves. (I develop Android Sync and other such services from outside of the Fennec build process.) A quick bisect shows that the last unsigned APK (no META-INF/* in APK) was: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-02-06-03-10-27-mozilla-central-android/gecko-unsigned-unaligned.apk and the first signed APK is: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-02-07-03-09-36-mozilla-central-android/gecko-unsigned-unaligned.apk
This was changed in bug 705807. You can still download it and sign it; you just need to un-sign it first, like this: #!/bin/sh # from mbrubeck set -e ORIG=$1 TMP=${ORIG%.apk}-tmp.apk OUT=${ORIG%.apk}-signed.apk cp "$ORIG" "$TMP" zip "$TMP" -d 'META-INF/*' jarsigner -keystore ~/.android/debug.keystore -storepass android -keypass android "$TMP" androiddebugkey zipalign -f -v 4 "$TMP" "$OUT" rm "$TMP" echo "Output in $OUT" the |zip ZIPFILE -d 'META-INF/*'| will remove the signature.
(In reply to Nick Alexander :nalexander from comment #0) > My use case: I have a script that downloads > latest/gecko-unsigned-unaligned.apk, signs it with a debug key, and aligns > it. I am steering new contributors to the android-services codebase to this > tool so that they don't need to build Fennec themselves. (I develop Android > Sync and other such services from outside of the Fennec build process.) > > A quick bisect shows that the last unsigned APK (no META-INF/* in APK) was: Argh! Off by one: The last unsigned APK (no META-INF/* in APK) was: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-02-07-03-09-36-mozilla-central-android/gecko-unsigned-unaligned.apk and the first signed APK is: http://ftp.mozilla.org/pub/mozilla.org/mobile/nightly/2013-02-08-03-10-53-mozilla-central-android/gecko-unsigned-unaligned.apk
(In reply to Aki Sasaki [:aki] from comment #1) > This was changed in bug 705807. > > You can still download it and sign it; you just need to un-sign it first, > like this: Agreed, but the filename is misleading and suggests an unintended change in the releng process.
We can stop uploading it if that's less confusing.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
(In reply to Aki Sasaki [:aki] from comment #4) > We can stop uploading it if that's less confusing. Is there a reason to upload gecko-unsigned-unaligned.apk? I need to touch this as part of making debug signing explicit in Bug 874132. We can: 1) kill gecko-u-u entirely. 2) debug sign gecko-u-u on all builds, developer and buildbot. 3) debug sign gecko-u-u locally and release sign on buildbot. Personal preference is 1, then 2. Option 3 violates principle of least surprise.
Flags: needinfo?(aki)
The only thing I can find referencing gecko-u-u is http://hg.mozilla.org/build/tools/file/0d1a88a0222c/scripts/android/android_snippet.py#l178 ; we need to change that before we can do option (1). How would (2) happen?
Flags: needinfo?(aki)
(In reply to Aki Sasaki [:aki] from comment #6) > The only thing I can find referencing gecko-u-u is > http://hg.mozilla.org/build/tools/file/0d1a88a0222c/scripts/android/ > android_snippet.py#l178 ; we need to change that before we can do option (1). Thanks for catching this. It looks trivial to change: it's just extracting application.ini from the apk. We could switch the APK name (irritating, since fennec-*24*.apk changes), or better yet, parse this from the JSON. Which also changes name. Sigh. > How would (2) happen? We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug 874132. It should work on the buildbots.
> > How would (2) happen? > > We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug > 874132. It should work on the buildbots. Unclear: and the jarsigner part will manually manage an Android debug keystore.
(In reply to Nick Alexander :nalexander from comment #7) > (In reply to Aki Sasaki [:aki] from comment #6) > > The only thing I can find referencing gecko-u-u is > > http://hg.mozilla.org/build/tools/file/0d1a88a0222c/scripts/android/ > > android_snippet.py#l178 ; we need to change that before we can do option (1). > > Thanks for catching this. It looks trivial to change: it's just extracting > application.ini from the apk. We could switch the APK name (irritating, > since fennec-*24*.apk changes), or better yet, parse this from the JSON. > Which also changes name. Sigh. We can't hardcode a name here, as this script runs on all branches where we have Android nightly updates. We could either get the json in a non-versioned copy, or maybe |make echo-variable-SOMETHING| to figure out what the apk name is? Then it would work in all cases except when we bump versions; the next nightly would fail in the apk download. > > How would (2) happen? > > We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug > 874132. It should work on the buildbots. If that works, while keeping the final fennec apk nightly- or release-signed, then this could also be a good option.
(In reply to Nick Alexander :nalexander from comment #8) > > > How would (2) happen? > > > > We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug > > 874132. It should work on the buildbots. > > Unclear: and the jarsigner part will manually manage an Android debug > keystore. If this happens, we have to nuke the debug keystore on a regular basis (per nightly?) since it expires after a year and builds fail after that. We may already be nuking the debug.keystore in automation due to this.
> > > How would (2) happen? > > > > We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug > > 874132. It should work on the buildbots. > > If that works, while keeping the final fennec apk nightly- or > release-signed, then this could also be a good option. Good point. I assume you already are, since there's quite a few things that are debug-signed on infra -- watcher.apk, sutagent.apk, fencp.apk. I have a :needsinfo on Bug 874132 to jmaher to confirm that; you might step in there if you know.
That was inteneded to be: (In reply to Nick Alexander :nalexander from comment #11) > > > > How would (2) happen? > > > > > > We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug > > > 874132. It should work on the buildbots. > > > > If that works, while keeping the final fennec apk nightly- or > > release-signed, then this could also be a good option. I'll move forward with (2), then: manually debug signing gecko-unsigned-unaligned.apk. This will minimize churn by not removing it and requiring a buildbot change. The final robocop.apk and nightly will be signed as they are now.
(In reply to Aki Sasaki [:aki] from comment #10) > (In reply to Nick Alexander :nalexander from comment #8) > > > > How would (2) happen? > > > > > > We're implementing a zip-and-jarsigner replacement for apkbuilder in Bug > > > 874132. It should work on the buildbots. > > > > Unclear: and the jarsigner part will manually manage an Android debug > > keystore. > > If this happens, we have to nuke the debug keystore on a regular basis (per > nightly?) since it expires after a year and builds fail after that. We may > already be nuking the debug.keystore in automation due to this. Good point. I assume you already are, since there's quite a few things that are debug-signed on infra -- watcher.apk, sutagent.apk, fencp.apk. I have a :needsinfo on Bug 874132 to jmaher to confirm that; you might step in there if you know.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.