signing key changed?

[IzzySoft]

My updater just refused to accept the latest release, claiming the signature would not match. Taking a closer look it indeed sems that the current release was signed by a different key (sha256: 1fc4de52d0daa33a9c0e3d67217a77c895b46266ef020fad0d48216a6ad6cb70) than the previous one (sha256: 94e6715957850cf5ec5e78b68587ee7128ba45e7323ba798c0269b4d8c695a99). May I ask what happened? There's no hint in the release notes.

[growse]

The old cert was too weak for the google store policies, so it got refreshed. Happened so long ago that I think I must have forgotten to add to the changelog, will update the README & CHANGELOG.

Correct SHA256 is 1F:C4:DE:52:D0:DA:A3:3A:9C:0E:3D:67:21:7A:77:C8:95:B4:62:66:EF:02:0F:AD:0D:48:21:6A:6A:D6:CB:70

[growse]

2.4.12 sent to Google for review.

Thanks for raising - please raise more if you see any issues. Google's rushed me into this slightly hacky release to hit an arbitrary deadline, so hyper-aware there may be more things that I've missed.

[IzzySoft]

First, thanks for outlining the details!

Changing the cert means those who have the app installed need to uninstall and re-install the app. They won't get any notification of available updates before having done that (as the update would be "incompatible" due to the different signature). There currently is no way to inform those folks (something we currently work on at F-Droid but are still at "design state"), so it should at least be pointed out with the changelogs in case someone looks it up wondering why there were no updates.

I'd then switch to permit the new signature, which means to remove all previous versions. To confirm it was really you, it would help if you could attach another APK of the same version which is signed with the old key (which only you could do, hence it would confirm the switch); I'd suggest a file name like owntracks-release-oss-v2.4.12_oldsig.apk and an explaining hint in the release notes. As soon as that's there, I'd verify once and then switch over; I'd suggest to keep that APK there so others can check independently.

As for description, screenshots and maybe even per-release changelogs: may I suggest to establish Fastlane structures here in your repo? Be welcome to use my Fastlane Cheat Sheet for guidance with that. It would empower you to define how your app is presented. Should you need help with that, let me know.

[growse]

Changing the cert means those who have the app installed need to uninstall and re-install the app. They won't get any notification of available updates before having done that (as the update would be "incompatible" due to the different signature).

I may be wrong, but doesn't this only apply to people who've manually installed the APK? If you're installing from the Play store, then that uses Google's signing key (and they take care of rolling that). If you're using F-Droid, then they have their own key they use for builds?

(This may be moot anyway for F-Droid, as the next version that'll be published there will be 2.5.0, which removes the problematic objectbox dependency).

o confirm it was really you, it would help if you could attach another APK of the same version which is signed with the old key (which only you could do, hence it would confirm the switch); I'd suggest a file name like owntracks-release-oss-v2.4.12_oldsig.apk and an explaining hint in the release notes

This is definitely a good point. I'll update the release notes and dig out the old key (if I can find it).

As for description, screenshots and maybe even per-release changelogs: may I suggest to establish Fastlane structures here in your repo? Be welcome to use my Fastlane Cheat Sheet for guidance with that. It would empower you to define how your app is presented. Should you need help with that, let me know.

Thanks - Fastlane seems to integrate better with F-Droid than TripleT (which I think is now discontinued?) so I should definitely put switching on the backlog. Hopefully it shouldn't be too hard, the fastlane docs look excellent.

[IzzySoft]

With F-Droid, that depends: if the app is set up for reproducible builds, APKs are signed by the resp. developers. If the app comes via my repo (as in this case here), the same. Only otherwise, F-Droid uses a signing key it specifically created for the app.

his is definitely a good point. I'll update the release notes and dig out the old key (if I can find it).

Thanks! That would be great. Please give me a ping when it's there (I will be quite busy for the next few days, but should respond soon afterwards).

Fastlane seems to integrate better with F-Droid than TripleT

True. While Triple-T seems to meanwhile work fine as well, Fastlane seems to be more stable (and btw is the only of the two supported by my repo).

Btw: You sound as if your app would be on F-Droid, but the link from your Readme gives a 404. The one to my repo would be this one.

[obfusk]

Btw: You sound as if your app would be on F-Droid, but the link from your Readme gives a 404.

It was disabled, see #1298.

[IzzySoft]

Ah, thanks for the pointer! I vaguely remembered something but did nor remember what it was that I thought to remember 🙈 (didn't we have that just yesterday somewhere else? LOL)

[IzzySoft]

I'll update the release notes and dig out the old key (if I can find it).

@growse did you meanwhile had a chance to do that? I'd like to make updates available again – but prefer to have the confirmation here if possible. So until now I receive a warning mail each time the repo updates, as your APK with the new key is not accepted before I switched out AllowedKeys.

[growse]

I've got the old keystore, just need to find time to actually do in between job / parenting / real-life / etc.

[IzzySoft]

Glad to read! Looking forward to the "proof" then with much optimism and enthusiasm even 😃

[growse]

Updated the github release.

[IzzySoft]

Thanks! I've fetched both APKs to compare them (ignoring the certs, I've expected everything else to be identical). Found some small differences, though – but those seem to be caused by "non-reproducible building" (one file, namely EventBusIndex.smali, has a lot of differences, but I have no idea what to make out of those; I'm no expert with that).

TL;DR: Looks good to me, basically.

@obfusk I hope you can confirm. What I did was basically the RB tests, which showed differences with the signature (to be expected), the classes.dex and (resulting from that) the baseline.prof. Ignoring the first and last. I used apktool to decompile, and then ran a recursive diff (was quite long, so I used meld to take a look at that). Apart from the named, the only differences found were in EventBusIndex.smali, as outlined. I tend to accept that as sufficient proof – unless you have objections.

(@growse I ask obfusk here as they have much more experience in this area than I have – and sharper eyes 😉)

[obfusk]

The diff is basically this:

--- /dev/fd/63	2023-09-04 01:06:54.774025649 +0200
+++ /dev/fd/62	2023-09-04 01:06:54.774025649 +0200
@@ -4,6 +4,8 @@
 
 package org.owntracks.android;
 
+import org.owntracks.android.data.repos.MemoryContactsRepo;
+import org.owntracks.android.ui.preferences.connection.ConnectionViewModel;
 import org.owntracks.android.services.BackgroundService;
 import org.owntracks.android.support.Events$RestartApp;
 import android.location.Location;
@@ -12,8 +14,6 @@
 import org.owntracks.android.support.Events$WaypointRemoved;
 import org.owntracks.android.support.Events$WaypointUpdated;
 import org.owntracks.android.support.Events$WaypointAdded;
-import org.owntracks.android.ui.preferences.connection.ConnectionViewModel;
-import org.owntracks.android.data.repos.MemoryContactsRepo;
 import org.greenrobot.eventbus.meta.SubscriberInfo;
 import org.greenrobot.eventbus.meta.SimpleSubscriberInfo;
 import org.owntracks.android.services.MessageProcessor;
@@ -43,25 +43,25 @@
         final int n3 = 1;
         array[n3] = subscriberMethodInfo;
         putIndex(new SimpleSubscriberInfo(MessageProcessor.class, array));
-        final SubscriberMethodInfo[] array2 = new SubscriberMethodInfo[n];
+        final SubscriberMethodInfo[] array2 = new SubscriberMethodInfo[8];
         final ThreadMode background = ThreadMode.BACKGROUND;
-        final String s2 = "onEventMainThread";
-        array2[0] = new SubscriberMethodInfo(s2, clazz2, background, 0);
-        array2[n3] = new SubscriberMethodInfo(s2, clazz, background, 0);
-        putIndex(new SimpleSubscriberInfo(MemoryContactsRepo.class, array2));
+        array2[0] = new SubscriberMethodInfo(s, Events$WaypointAdded.class, background, 0);
+        array2[n3] = new SubscriberMethodInfo(s, Events$WaypointUpdated.class, background, 0);
+        array2[n] = new SubscriberMethodInfo(s, Events$WaypointRemoved.class, background, 0);
+        array2[3] = new SubscriberMethodInfo(s, clazz2, background, 0);
+        array2[4] = new SubscriberMethodInfo(s, Events$MonitoringChanged.class, background, 0);
+        array2[5] = new SubscriberMethodInfo(s, MessageTransition.class, background, 0);
+        array2[6] = new SubscriberMethodInfo(s, Location.class, background, 0);
+        array2[7] = new SubscriberMethodInfo(Events$RestartApp.class);
+        putIndex(new SimpleSubscriberInfo(BackgroundService.class, array2));
         final SubscriberMethodInfo[] array3 = new SubscriberMethodInfo[n3];
         array3[0] = new SubscriberMethodInfo(clazz2);
         putIndex(new SimpleSubscriberInfo(ConnectionViewModel.class, array3));
-        final SubscriberMethodInfo[] array4 = new SubscriberMethodInfo[8];
-        array4[0] = new SubscriberMethodInfo(s, Events$WaypointAdded.class, background, 0);
-        array4[n3] = new SubscriberMethodInfo(s, Events$WaypointUpdated.class, background, 0);
-        array4[n] = new SubscriberMethodInfo(s, Events$WaypointRemoved.class, background, 0);
-        array4[3] = new SubscriberMethodInfo(s, clazz2, background, 0);
-        array4[4] = new SubscriberMethodInfo(s, Events$MonitoringChanged.class, background, 0);
-        array4[5] = new SubscriberMethodInfo(s, MessageTransition.class, background, 0);
-        array4[6] = new SubscriberMethodInfo(s, Location.class, background, 0);
-        array4[7] = new SubscriberMethodInfo(Events$RestartApp.class);
-        putIndex(new SimpleSubscriberInfo(BackgroundService.class, array4));
+        final SubscriberMethodInfo[] array4 = new SubscriberMethodInfo[n];
+        final String s2 = "onEventMainThread";
+        array4[0] = new SubscriberMethodInfo(s2, clazz2, background, 0);
+        array4[n3] = new SubscriberMethodInfo(s2, clazz, background, 0);
+        putIndex(new SimpleSubscriberInfo(MemoryContactsRepo.class, array4));
     }
     
     private static void putIndex(final SubscriberInfo subscriberInfo) {

And that is a known RB bug in eventbus: greenrobot/EventBus#715

[IzzySoft]

Thanks Fay! So my observation was right. Great, puzzle solved! The new signing key is hereby enabled in my repo now (and the old one disabled as well as its APKs are removed). With the next sync, the new version (v2.4.12) will be listed then – thanks @growse for your efforts!