FFUpdater from F-Droid repo fingerprint

[quaqo]

Is something recently changed? I skipped a few relases and now FFUpdater shows itself in the list of "updatable" apps, but alerting that it has a different fingerprint.

I don't remember this being a thing before, and I don't see any mention of this in the changelog.

In fact I remember the self-update function excluded the code from running if FFUpdater was installed from the F-Droid repo and thus signed with the F-Droid signature.

[Tobi823]

I thought that it would be more transparent. FFUpdater could update itself if I would not be installed with F-Droid. It is just an information and not a warning.

In retrospect I think it is a bad idea because it creates confusion.

[Tobi823]

What do you think - should I hide the FFUpdater entry in the app if the user installed FFUpdater via F-Droid?

[quaqo]

What do you think - should I hide the FFUpdater entry in the app if the user installed FFUpdater via F-Droid?

It depends on what you're trying to achieve. Just some random thoughts:

• It seems to me that the recommended installation in the README and here is throu F-Droid: this means the default state is "everyone will display that message" and thus creates confusion because it is inconsistent;

• I didn't find this change in the Changelog (but maybe I missed it), so it alarmed me a bit.

Now that you explain I'm 100% ok with it, I still think there's some inconsistency in alerting users that your reccomended method of installation has potential fingerprint issues.

I'd check against both F-Droid signature and yours, AND display that message if it's neither. That could be actually useful, as it would alert the user of a potential problem (malicious fork?).

[Tobi823]

it would alert the user of a potential problem (malicious fork?).

I have not thought of that

I did not make up my mind yet - maybe I will:

• hide the entry
• or display, that it was installed by F-Droid (and can't update itself.)

[quaqo]

Either way I think you should document it. Your (very valuable!) software has the ability to be a potentially security risk for users if mismanaged. You've been thorough in providing the GPG key that signs the commits, and so on. I think transparency and documentation are important, especially because most people who use FFUpdater are privacy or security oriented (or both!). :-)

I think both options are good, but if you go with the second document the change and state somehow if F-Droid is still your reccomended install method for FFUpdater (maybe it's not because of timing?).

Just my two cents!

[Sanaki]

There's always the option of making both use the same signature as well:

https://f-droid.org/docs/Reproducible_Builds/

[Tobi823]

@Sanaki sounds interesting but I'm unsure how to setup "reproducible builds"

Is it enough to add Binaries: https://github.com/Tobi823/ffupdater/releases/download/%v/ffupdater-release.apk to https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/de.marmaro.krt.ffupdater.yml (with a pull request)?

(I guess I can use the configuration of another app as orientation like https://gitlab.com/fdroid/fdroiddata/-/blob/master/metadata/me.gloeckl.fallasleep.yml)

(It seems that I also need AllowedAPKSigningKeys in de.marmaro.krt.ffupdater.yml)

[Tobi823]

Note to myself:

Binaries: https://github.com/Tobi823/ffupdater/releases/download/%v/ffupdater-release.apk
AllowedAPKSigningKeys: f4e642bb85cbbcfd7302b2cbcbd346993a41067c27d995df492c9d0d38747e62

After signing my APK (with my key) I have to extract the signature and uploaded it to fdroiddata -> see "Publish both (upstream) developer-signed and F-Droid-signed APKs"

[Tobi823]

This issue now is important because the duplicated issues are annoying :D

https://gitlab.com/fdroid/fdroiddata/-/merge_requests/13713

[Tobi823]

Done. On F-Droid two versions are now hosted - the version signed by F-Droid and the version signed by me. If the user uses the F-Droid version, he/she can see an information that he/she should switch to the version signed by me. If the user uses my version, FFUpdater can update itself with the releases from Github.

Unfortunately this will delay new releases from F-Droid further because every time I have to make a pull requests to release a new version. But there is nothing I can do to speed up F-Droid.