After reading the F-droid docs, I still don’t get how apps are updated. If I got it right, app developers can optionally include a flag in the metadata of their apps so that F-Droid periodically checks whether an app has been updated upstream or not. If F-Droid detects an update, this app can be added to a list with apps to build for the next build process which runs daily. (Apps aren’t automatically added to this list even if they have this flag set according to the docs. Why?)
However, what happens when the metadata of an app didn’t include this flag? Does F-Droid staff have to manually check for updates?
Then, it seems that some apps include this flag and updates are available upstream for months but nothing happens (app page on F-Droid doesn’t show failed builds, but shows that there are new versions upstream). Why aren’t such apps built?
If the build process runs daily, I should get updates daily (I mean synchronizing with the F-Droid repo here). However, I sometimes get a repo update only once a week. Why?
My last point:
KnownVuln has been added last year, but it seems that it only checks whether an app uses outdated OpenSSL in its source. No further security checks, right? According to the KnownVuln category, nearly 50% of all apps in the main repo have this anti-feature.
As a user of the F-Droid client, I’m somewhat confused when I come across such anti-features. Is this relevant for the security and integrity of my device? Why does F-Droid provide apps with known vulnerabilities after all?
Sorry, but your answer doesn’t answer any of my questions. I try to be more clear:
How are apps without auto update flags updated? Are these apps manually checked and added to the build queue?
Why are some apps with auto update flag set AND with detected updates upstream AND without failed build still not updated (even after several months)? So F-Droid detected updates upstream but they aren’t built. Why?
Why do I get an update for the whole F-Droid repo sometimes once a day, sometimes once a week, if F-Droid builds apps daily (according to the docs)? This would imply that there are absolutely no updates for any app in the main repo for days.
KnownVuln is explained here: https://f-droid.org/wiki/page/Antifeature:KnownVuln. However, this page states that there is only a check for outdated OpenSSL for this anti-feature. Nearly 50% of all apps on F-Droid have the KnownVuln tag according to this site: https://f-droid.org/wiki/page/AntiFeatures. So why does F-Droid provide these ~1300 apps with known vulnerabilities after all?
Okay, so in general, apps without update flag have to be manually updated by someone because F-Droid can’t automatically detect updates. Example: Omni Notes (Omni Notes | F-Droid - Free and Open Source Android App Repository). F-Droid detected a new version (which is already more than two months old) however there is no update since auto updates are disabled and no one at F-Droid updated it.
Some mixed examples: Transportr (latest version 2.0.0, auto update flag is enabled, F-Droid didn’t detect this update after 6 days) or Simple-Calendar (latest version 4.1.2, auto update flag is enabled, F-Droid didn’t detect this update after 5 days). There are more examples however I don’t want to list all of them here.
Okay, thx
Okay, then it is absolutely not clear after reading the official wiki: https://f-droid.org/wiki/page/Antifeature:KnownVuln, because there is also DisabledAlgorithm. According to your explanation and these wiki pages, MD5 is tagged as DisabledAlgorithm AND KnownVuln?
According to the Category:Apps page, these are about 47% of all apps on F-Droid with these anti-features.
When I go to the wiki page explaining “DisabledAlgorithm” it states that this anti-feature is all about MD5 signatures.
However, the page explaining “KnownVuln” states that “KnownVuln” either means that there is an MD5 signature or an outdated version of OpenSSL is used. So it seems that all apps with the anti-feature “DisabledAlgorithm” are also tagged “KnownVuln”.
For me (and others when I look at Gitlab issues) it’s really confusing. Why aren’t they named like:
OutdatedOpenSSLInUse (only the OpenSSL topic)
MD5SignatureInUse (only the MD5 signature topic)
Examples for this are directly accessible via the F-Droid anti-feature page.
Other apps need love (aka someone to edit the metadata BUILD SECTION and add the new versions, check if it builds on their machines first, then push a MergeRequest): F-Droid Monitor
Except the huge effort @Izzy pulled to check all the apps, others need to check their favourite apps and help somehow.
1530 to be precise. And actually even twice: first to check URLs, versions (marking for update where needed), availability, and then another time to check which descriptions needed updates. The latter turned out to about 20% – and resulted in 19 MRs with at average about 12 app descriptions each (two of them are still waiting to be merged: MRs 3439 and 3441 – the latter one being the biggest batch with 23 app descriptions).
So yes, it’s possible – but quite time consuming. And that were one-time jobs. I wouldn’t want to do that every week, to manually check for updates. That’s why we prefer tags, so checkupdates can look out and alert us where updates are needed (see Apps to Update).
That’s the best we can do for apps without AUM (Auto Update Mode), indeed. You could also check your favorite apps whether they don’t have AUM configured (and Update Check Method most likely not set to “Tags”), then approach the developers and suggest they’d use tags.
But even for those apps already having AUM activated, that doesn’t necesarily mean “immediate updates”. If you take a look behind that link you’ll see the queue has currently 195 apps listed. Now take a look at the commits/MRs and see how many people working on this (hint: your fingers are more than sufficient for counting here). Each of those 195 apps must be looked at, a build needs to be setup and tested, and only then it can be commited.
Then we must be lucky that the build server hasn’t got a hickup again …
https://f-droid.org/wiki/page/Antifeature:KnownVuln is mostly the old, deprecated MD5 signature with 2 with old OpenSSL. On the wiki, it gives a count of all apps that have one APK affected ever. In fdroidclient, it shows the Anti-Features that apply to the APK you’re installing.
