Towards a Reproducible F-Droid | Hacker News Reader

Towards a Reproducible F-Droid

f-droid.org

219 pointsmikece46 comments

The whole approach to updates in the FOSS community needs a rethink imho. Security is obviously an overarching imperative and people have been conditioned to do their part (update frequently) but the user experience keeps deteriorating.

There are constant updates, there is no distinction of whether they are imprortant or not (applies across the board of stores) but on on f-droid some developers seem to ne pushing things nightly. They get larger over time (KDE is now several GB as somehow almost everything must be updated every month) or they need app-by-app approval (f-droid)

Throwing out some ideas: initiate the concept of security updates (microsoft has it for ages). Bundle other updates in time (eg monthly). And definetely allow the user to have a set of apps that dont need individual approval all the time.

Android offers seamless updates for apps from third party stores targeting API 29 since Android 12 via the REQUEST_INSTALL_PACKAGES permission: https://support.google.com/googleplay/android-developer/answ... https://developer.android.com/reference/android/content/pm/P... There are issues on GitLab covering this: https://gitlab.com/fdroid/fdroidclient/-/issues/1836

These devs are, quite plainly, gaming the system (I'm talking about F-Droid specifically). They have found that being on top of 'last updated' list leads to more installs, and are churning out versions.

I'm surprised reproducibility isn't a bigger deal for the OSS community.

Reproducibility is a nice-to-have, when open source is often missing basic table stakes like correct functioning.

F-Droid in particular a) requires users to manually confirm updates, because they haven't implemented the new API that'd let them update apps silently b) used to throw errors when doing so, so each update turned into a minute of fiddling.

https://gitlab.com/fdroid/fdroidclient/-/issues/1843

https://gitlab.com/fdroid/fdroidclient/-/issues/1836

Personally I'm glad that I have to manually confirm updates, but folks who want their apps changed without notice should have the option.

On the last three devices I installed F-Droid on, it was unable to update itself or update apps period. When I hit the Update button it would throw up a generic error message and Googling that message yields hits for multiple F-Droid issues from the past several years.

They have a long way to go before their software is usable. It's a shame because I would happily promote F-Droid to other people, if it worked.

I highly recommend Neo Store. It's a drop-in replacement for f-droid that leverages the newer Android API for seamless updates. Been using it for months happily.

It probably isn't helpful, but updates do work for me on the ancient android phone I've got apps on (Markor, Simple Gallery Pro, NewPipe). Maybe they've fixed it?

The issue you describe is may be caused by the Android ROM on the phone. I've seen it work without issue on Motorola and Pixel phones, but struggle on OnePlus.

That's odd. I've never had an issue with F-Droid over many years and across many devices.

There's a difference between manually confirming updates and manually installing the update APKs. Having to go through the "install", wait 10 seconds, "Ok" process for every single app you want to update is a terrible experience and is the main reason half of the apps on my non-rooted phone are outdated.

Used to? I'm pretty sure it still does. There are comments on that issue from as recently as 6 days ago. Personally I can't recall a time when manual updates on F-Droid ever worked consistently.

Yeah, I wasn't sure because I hadn't seen any updates in a while

Neo Store is an alternative F-Droid client that supports that API.

Who runs Neo Store and why do you trust them?

It's just another client that (by default) uses the official F-Droid repo

There's also aurora droid

If you have f-droid privilege escalation patch the updates are automatic and seamless; MicroG version of LineageOS comes with it and so there's no need to root.

There's a joint effort for reproducible builds, and several Linux distros (Arch, Debian, Fedora and SUSE) along with various BSDs and other high-profile projects are participating: https://reproducible-builds.org/who/projects/

It's surprising that Flathub and Canonical's Snapcraft aren't involved in the Reproducible Builds initiative, since they're important distribution channels for end-user applications that could read your ssh keys and wipe your hard-drive if the distribution chain is compromised.

Those projects were created because maintainers want things as easy as NPM because the traditional path requires care, signing, and process. Security was never the goal.

IMO you're exaggerating a bit, but there's quite some truth in there. Flatpak has some security features and is by itself not a bad design, but the ecosystem's current state isn't really utilizing those.

Snap is a whole other can of worms. The ecosystem is like canonical's personal play store/app store.

Despite the downvotes you are spot on.

How is Nix not mentioned in this thread? The OSS community isn't a single monolithic entity. Nix devs and users are 100% on board with reproducibility.

For Android, there is Nix-on-Droid, built on top of Termux [1]. It would be wonderful if the Fdroid repository were made available as nix packages, but I don't believe that this is the case yet.

[1] https://f-droid.org/en/packages/com.termux.nix/

Arch Linux is heavily invested into it:

- https://reproducible.archlinux.org/ - Attempts to reproduce the distributed binary packages from source using reproducible builds tooling. This already works for a big chunk of packages.

- https://github.com/archlinux/archlinux-repro - This is a wrapper for Arch Linux build tooling that creates a build environment in a container that has the same packages installed as the original build environment back then. Software is expected to build reproducible in this environment and many ecosystems already do by default (Rust for example, to name one).

- https://github.com/kpcyrd/rebuilderd - This monitors the packages in Arch Linux, runs archlinux-repro on all of them and hosts the results. There are other projects supported but Arch Linux works best at the moment, and archlinux-repro offers the best integration I'm currently aware of.

There are surprisingly few people interested in running this stack on their own for verification purpose though.

As opposed to openbsd which is pushing hard for the complete opposite. unknowable builds.

https://undeadly.org/cgi?action=article&sid=20170701170044

https://undeadly.org/cgi?action=article&sid=20230119075627

Kernel relinking needs to happen on the user's system anyway because the prebuilt builds are not unknown (they are public for anybody to download). It's like ASLR at runtime vs ASLR at build time.

Since these binaries are known anyway they might as well use a seed to allow verification of the published binaries with reproducible builds, then relink them into an unknown binary on the user's system after install (for example during boot as described in the 2nd post).

I'm surprised installing updates in the background instead of requiring the user to manually install each and every update for each and every app is not a bigger deal for F-Droid.

Installing updates in the background requires special permissions that require google's blessing. For now, the workaround is a Magisk/Xposed/Lsposed module to give those low level permissions to the F-Droid app.

Not anymore since Android 12. As far as I know, if the installation (or update) of app A through app B is approved once, app B is now free to update app A in the background without a prompt.

Not automatically. It requires the use of a (new in Android 12) API. But you're otherwise right.

Yes, but F-Droid isn't on the play store so it wouldn't matter if they get Google's blessing to upload the app to the Play Store. They can just distribute the app with background installing capabilities from their website like they already do.

There is a Magisk module that gives FDroid the permissions to do this. I get updates automatically on my phone. Or you can use ROM that already has it built in, like Lineage+microg.

Updates in the background sounds... Bad? Not even play store does that to me.

This is the default iirc because that's what works for computer illiterate people. My partner specifically disabled that and does manual updates instead (I don't primarily use the Play store on my own device myself, so I don't have enough experience to judge whether this was user error). Despite that, their weather app got updated at some point after like five years of not updating it, and now everything (startup and detail screens) takes five times longer to load and it doesn't show the cities anymore that they want to see (can only show N on the screen and they iirc used to have 3 more or something). Of course there's no way to downgrade like you could on F-Droid (though, to be fair, it doesn't have releases going five years back, but it would also just never force this and it'd be safe to do updates intermittently because you can always choose "nah, don't like this change, I'll go back").

The closest experience I have is a GrapheneOS device where, after installing the Play Store, it ~daily tries to background install some VR app, no idea what that's about (purple hexagon logo, don't remember the name). I don't want this VR game on a work device. Installation fails because it requires manual confirmation (the store doesn't have background install permissions, which I think confuses the heck out of this google thing which is used to being a backdoor with superpowers) but the home screen keeps doing this animation to show another where this app is now loading, and fails some time later. For some reason it stopped prompting me with every attempt, not sure how I made it do that, but it switching home screens whenever I pick up the device is also annoying.

Background installs are totally a thing on the Play Store.

I use GrapheneOS too. I had that same Play Store prompt to install the purple AR app. "Google Services for AR" or something. For me, I'm pretty sure it was a dependency for Snapchat.

From my limited Googling at the time it seems you will only be prompted to install it if you already have an app installed that depends on it for certain functionality. Do you have any apps that might want to use the camera with AR-like effects?

Personally, I also stubbornly pressed "decline" on all the requests to install it. However, I gave in once I realised that:

1. I was probably the one that caused the install prompt (by installing Snapchat)

2. The shadiness of the app would likely not be worse than the other similar Google services I had already voluntarily installed

3. It would likely not be active except for when I'm using Snapchat

Now I haven't thought about that hassle in weeks.

Phyphox might be the one, I think that has some AR functionality though I forgot for what. Thanks for the hint!

I think it's a good thing overall, because most people would fall way behind on security fixes otherwise.

Apps in general get better over time. As a platform having autoupdates will improve the average experience of your users as they will be using better apps that have less issues and less crashes.

Yes, the play store already does this.

> Apps in general get better over time.

As monetization becomes a bigger concern for a new app/service that was successful, I would tend to think that after a few cycles of getting better apps in general will get worse by increasing the amount of advertisements, requests for subscribing to something and dark pattern usage.

There's also the case of apps getting worse due to some company wanting to deprecate some feature in favor of another that is actually worse (some chat application that changed the way of doing video calls to take three clicks with loading times instead of one click ; some VPN app which changed the method of logging in so it takes one minute instead of one second)

Reply on news.ycombinator.com