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.
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/
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.
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.
> 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.
> 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.
[+] [-] college_physics|3 years ago|reply
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.
[+] [-] jhoho|3 years ago|reply
[+] [-] throwawaybutwhy|3 years ago|reply
[+] [-] ThrowawayTestr|3 years ago|reply
[+] [-] tgsovlerkhgsel|3 years ago|reply
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
[+] [-] codewiz|3 years ago|reply
[+] [-] colordrops|3 years ago|reply
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/
[+] [-] kpcyrd|3 years ago|reply
- 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.
[+] [-] somat|3 years ago|reply
https://undeadly.org/cgi?action=article&sid=20170701170044
https://undeadly.org/cgi?action=article&sid=20230119075627
[+] [-] charcircuit|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Hizonner|3 years ago|reply
[deleted]
[+] [-] notpushkin|3 years ago|reply
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.
[+] [-] yjftsjthsd-h|3 years ago|reply
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.
[+] [-] unknown|3 years ago|reply
[deleted]