F-Droid repository for tt-rss

[webracer999]

OK, f-droid crashes, but I think there is a signature problem in the repo.

https://srv.tt-rss.org/fdroid/repo/index-v1.jar
→ keytool -printcert -file META-INF/977ADA9E.RSA

outputs:

SHA256: C1:17:B9:EA:ED:FC:BA:8B:EF:73:26:3C:A9:49:0D:B9:05:ED:FF:FE:5D:7C:07:1F:FA:AE:15:2A:75:FC:B6:E4

This footprint is also displayed in f-droid repo details:

https://srv.tt-rss.org/fdroid/repo/org.fox.ttrss-fdroid.apk
→ apksigner verify --print-certs org.fox.ttrss-fdroid.apk

outputs:

Signer #1 certificate SHA-256 digest: c74664ba0fd8f8c97e2a548926609df1369236dd9d9d14c0e5c20b8c2b08cf06

Or am I on the wrong way and the jar and apk signing keys doesn’t have to be the same?

BTW: The stack trace in f-droid, when opening the app details of “Tiny Tiny RSS” after it was installed (unless it isn’t installed app details can be opened):

java.lang.NullPointerException: Attempt to invoke virtual method 'boolean java.lang.String.equals(java.lang.Object)' on a null object reference
	at org.fdroid.fdroid.data.App.findSuggestedApk(App.java:555)
	at org.fdroid.fdroid.data.App.findSuggestedApk(App.java:537)
	at org.fdroid.fdroid.data.App.update(App.java:299)
	at org.fdroid.fdroid.views.AppDetailsActivity.updateAppInfo(AppDetailsActivity.java:747)
	at org.fdroid.fdroid.views.AppDetailsActivity.onVersionsChanged(AppDetailsActivity.java:734)
	at org.fdroid.fdroid.views.AppDetailsActivity.$r8$lambda$lgtpLd3OEgQKVJA9DmWlIbk-RDQ(Unknown Source:0)
	at org.fdroid.fdroid.views.AppDetailsActivity$$ExternalSyntheticLambda2.onChanged(Unknown Source:4)
	at androidx.lifecycle.LiveData.considerNotify(LiveData.java:133)
	at androidx.lifecycle.LiveData.dispatchingValue(LiveData.java:151)
	at androidx.lifecycle.LiveData.setValue(LiveData.java:309)
	at androidx.lifecycle.LiveData$1.run(LiveData.java:93)
	at android.os.Handler.handleCallback(Handler.java:942)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loopOnce(Looper.java:226)
	at android.os.Looper.loop(Looper.java:313)
	at android.app.ActivityThread.main(ActivityThread.java:8757)
	at java.lang.reflect.Method.invoke(Native Method)
	at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1067)

[fox]

the repo is supposed to be unsigned, idk if it matters or not.

i’ve just added the repo to foxy droid (which is a imo much better fdroid repo client) and everything seemed to work properly. regardless of something being wrong with the repo (or not) the application shouldn’t crash. maybe report this to fdroid app devs?

[webracer999]

Yes, I agree with you - f-droid shouldn’t crash. I’ve created an issue report: App details: java.lang.NullPointerException (#2598) · Issues · F-Droid / Client · GitLab

But … I think there is another issue with the repo signature …
I tried to pass the crash and also tried to throw away the signature. Then I get the details screen, but no compatible app versions are shown.
As far as I can tell your repo is signed. F-droid seems to use the signature of index-v1.jar

[fox]

maybe they’ll figure out why it crashes and what needs to be done to fix the repo.

[webracer999]

Yeah, I tried to fix it on my own in f-droid, but unfortunately I’m lost in f-droids source code. I’m coding for years and also as profession. But Java just as a hobby and I only have very limited knowledge in Android development.

I’m excited what f-droid team will tell. - Because what’s strange: If it’s a signature failure - why can it be installed the first time?!

[fox]

have you tried adding the same repo using foxy droid?

[webracer999]

Yes, Foxy Droid works and is a workaround for me.

Meanwhile F-Droid team has written:

this repo is created with a very old version of fdroidserver which publishes signature information with MD5 still. Is there any way the repo owner could update to a newer version?

Don't crash when app has no signer at all (!1217) · Merge requests · F-Droid / Client · GitLab will fix the crash, but users won’t be able to update the apps without SHA256 signer, because fdroidclient doesn’t support the old MD5 sig anymore, so it considers the signatures to be incompatible.
(Torsten Grote, App details: java.lang.NullPointerException (#2598) · Issues · F-Droid / Client · GitLab)

So I think that’s the point, why Foxy Droid still works.
Is it possible that you update to a newer version of fdroidserver?

[fox]

@webracer999

Is it possible that you update to a newer version of fdroidserver?

that entirely depends on how backwards-compatible the newer version is. do they have a migration guide or something? idk.

@webracer999

will fix the crash, but users won’t be able to update the apps without SHA256 signer,

well it won’t crash but without updating the apps it makes the whole thing useless then.

honestly i’m not sure if the repo is even needed. all apks have built-in update notifications anyway. it might be easier to just keep those with direct downloads and remove the fdroid thing altogether. it feels like an unnecessary kludge.

e: it would be a lot easier for my CI processes anyway if i won’t have to invoke their super-slow docker-based repo builder.

the whole “we’re not going to allow you to install the apps because of some imaginary security circus-tier scenario we’ve imagined where someone goes for a repo signature collision (i guess) which would also involve an SSL MITM and somehow bypass APK signature afterwards” doesn’t fill me with desire to deal with any of this at all.

[fox]

now that i think about it, i’m using gitlab already anyway so it would make sense to use gitlab CI for build artifacts (in this case, APKs) instead of doing this song-and-dance copying the file somewhere for no particular reason.

i.e. https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/jobs/65/artifacts/browse/org.fox.ttrss/build/outputs/apk/fdroid/ etc

to make it a bit easier to figure out CI could generate a release linking to the artifact.

[fox]

to give a concrete example on how this could work:

https://gitlab.tt-rss.org/main/the-epube-android/-/pipelines/161

above pipeline builds an APK and creates a project release visible here

https://gitlab.tt-rss.org/main/the-epube-android

which leads to here

https://gitlab.tt-rss.org/main/the-epube-android/-/releases

where there’s an APK link

the whole thing is built using a dead simple CI template (https://gitlab.tt-rss.org/ci/ci-templates/-/blob/master/.ci-build-apk-fdroid.yml) which is about as straightforward as you can get.

this is how this should work. screw stupid bespoke repos and screw f-droid in particular.

[webracer999]

For me: I would be happy, if there’s a f-droid repo. But - I got your point above and I’m not the person who has to maintain the repo.
So for me it’s also okay to rely on the app internal updater or something similar (e. g. I track a lot of software releases [Linux/Windows] on github through the RSS-feeds).

I don’t understand what the gitlab CI changes (sorry, I’m technically not really on this topic) beside the app internal updater.

If I have two wishes, they would be:

• Delete the f-droid repo, if you don’t maintain it in the future - so it’s clear for the user
• What do I have to “migrate” to the “new” update method? Do I have to reinstall the app etc.?

[fox]

@webracer999

I don’t understand what the gitlab CI changes

basically it’s something that is a lot easier, for me, to deal with. I’m using CI anyway so it makes sense to use it for binary releases too, that’s pretty much the gist of it.

@webracer999

Delete the f-droid repo, if you don’t maintain it in the future - so it’s clear for the user

yep.

@webracer999

What do I have to “migrate” to the “new” update method? Do I have to reinstall the app etc.?

no, you won’t have to reinstall anything, the APK is signed with the same key.

https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/releases - installing an APK from here should just work.

fixing in-app update notifications to point to gitlab would involve some digging so i can’t give a ETA. in any case, tt-rss apk updates very rarely so it’s not a big deal.

as a workaround, you can subscribe to the project RSS feed, if there’s a new master commit = there’s a new release.

[fox]

update: fdroid repo / web glue is no more.

[webracer999]

Ok, thank you very much!

[fox]

i’ve updated android build CI pipelines so that

1. gitlab releases contain apk version info in readable form - https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/releases/
2. json files necessary for in-app update notifications to work are also generated and published during build - https://gitlab.tt-rss.org/tt-rss/tt-rss-android/-/jobs/611

[conrad784]

@fox

no, you won’t have to reinstall anything, the APK is signed with the same key.

I might have a very old version, is it expected that I can not easily update to the latest gitlab release?

[fox]

if you installed from play store originally, you’ll have to reinstall because the signing key is different. it’s the same key from then on though.

[conrad784]

Yeah, now the build number hast a -fdroid suffix, I guess I was still on a Play Store version. Feels a little bit snappier, should not have waited so long for the update

Did I understand correctly that it now reaches out to your server to check if there is an update when the app starts? Would it be possible to make this optional and only trigger this manually?

[fox]

nope, can’t disable it at the moment. i could make an opt-out checkbox i guess.

its a simple json file https://srv.tt-rss.org/fdroid/updates/org.fox.ttrss.json