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.
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.
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.
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.
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.
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.
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.
- 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.
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.
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.
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
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.
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)
> unless something is actually checking that what's "reproduced" is the same as what the original developer originally produced
They do.
The way it works is, developer builds and signs the APK and sends it to F-Droid. F-Droid then builds the app from source again, and if it gets the same APK, it publishes the one with the developer's signature.
In this scheme, they don't sign the APKs – the developer does. They just verify that the APK corresponds to the source code.
I don't think there's any point in adding an independent auditing thing to this – is three pairs of (automated) eyes that better than two? But of course you can do that, the tooling for verifying it is open source.
(Of course, all of that doesn't work if the app doesn't support reproducible building, which is the majority of apps on F-Droid now – hence this post calling for a change)
> Did they SERIOUSLY offer "Google does it" as a justification for their signing the APKs?
I don't think that's a justification. It's them saying that that's how another party does it, then describing the problems with that approach in contrast what they're doing.
> unless something is actually checking that what's "reproduced" is the same as what the original developer originally produced.
As my sibling comment says, F-droid does verify it.
> And it is definitely better to trust only the developers than to trust both the developers AND the repo maintainers.
... Which this provides, by bringing us back to a point where you only have to trust the developer, and even then you have to trust them less because somebody else (F-droid) has verified that the binaries match the source code that they've provided.
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.