JAR signer warnings do not point out which package they apply to
As the new Android client requires the index-v1.jar
and won't work without that, I have to switch my main repo to the updated fdroidserver. However, that poses some issues: Loads of warnings which cannot be "used". Examples:
WARNING: META-INF/kotlin-runtime.kotlin_module not protected by signature. Unauthorized modifications to this JAR entry will not be detected. Delete or move the entry outside of META-INF/.
Error:
This jar contains entries whose certificate chain is not validated.
Warning:
This jar contains signatures that does not include a timestamp. Without a timestamp, users may not be able to validate this jar after the signer certificate's expiration date (2288-08-01) or after any future revocation date.
Without the detail which package they refer to, they are not really useful: I'm having almost 350 apps in my repo, each with up to 3 APK files. Additionally, there could be multiple lines per APK, so "simple counting" is out as well. What makes it worse: those messages are not only thrown when a package is processed for the first time, but on each run of fdroidserver update
. So while with the "old code" I got only those errors/warnings referring to newly added files, now I get the full load each time (Cron mail for automated runs), which makes detecting problems with new files hard or almost impossible (with 600+ APK files in the repo), and one never knows if that 200kB mail can be ignored or one has to check each of the ~400 lines for possible trouble. Nothing to be identified "on a quick glance", as it was with the "old code" – thus making maintenance hard.
Those errors/warnings are not thrown by fdroidserver itself (at least I couldn't find the string "not protected by signature" in its sources) – so it most likely comes from some "external tool" (JAR signer/APK signer).
Is there something that can be done to make those messages helpful – eg. capturing the output and, if non-empty, pre- or suffix it with the filename (or packagename + version)?
PS: it's probably apksigner
who's responsible here, as it's installed on my machine. Though the same might apply to jarsigner
unless that was what was used in the "old code" (as the issue didn't exist there).