7 ms·

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

codewiz 4y ago
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/ https://reproducible-builds.org/who/projects/
- codewiz 4y ago
  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.
  - lrvick 4y ago
    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.
    - Vogtinator 4y ago
      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.
    - goodpoint 4y ago
      Despite the downvotes you are spot on.
deleted 4y ago
[deleted]
tgsovlerkhgsel 4y ago
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/1843 https://gitlab.com/fdroid/fdroidclient/-/issues/1836 https://gitlab.com/fdroid/fdroidclient/-/issues/1836
- NoahKAndrews 4y ago
  Neo Store is an alternative F-Droid client that supports that API.
  - wolverine876 4y ago
    Who runs Neo Store and why do you trust them?
    - escalt 4y ago
      It's just another client that (by default) uses the official F-Droid repo
  - wkat4242 4y ago
    There's also aurora droid
- autoexec 4y ago
  Personally I'm glad that I have to manually confirm updates, but folks who want their apps changed without notice should have the option.
  - safety1st 4y ago
    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.
charcircuit 4y ago
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.
- aordano 4y ago
  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.
  - derkades 4y ago
    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.
    - MishaalRahman 4y ago
      Not automatically. It requires the use of a (new in Android 12) API. But you're otherwise right.
  - charcircuit 4y ago
    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.
- singpolyma3 4y ago
  Updates in the background sounds... Bad? Not even play store does that to me.
  - Aachen 4y ago
    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.
colordrops 4y ago
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/ https://f-droid.org/en/packages/com.termux.nix/
somat 4y ago
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=20170701170044 https://undeadly.org/cgi?action=article&sid=20230119075627 https://undeadly.org/cgi?action=article&sid=20230119075627
- kpcyrd 4y ago
  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).
kpcyrd 4y ago
Arch Linux is heavily invested into it: - https://reproducible.archlinux.org/ 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 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 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.

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/ https://reproducible-builds.org/who/projects/

codewiz 4y ago
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.
- lrvick 4y ago
  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.
  - Vogtinator 4y ago
    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.
  - goodpoint 4y ago
    Despite the downvotes you are spot on.

deleted 4y ago

[deleted]

tgsovlerkhgsel 4y ago

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/1843 https://gitlab.com/fdroid/fdroidclient/-/issues/1836 https://gitlab.com/fdroid/fdroidclient/-/issues/1836

NoahKAndrews 4y ago
Neo Store is an alternative F-Droid client that supports that API.
- wolverine876 4y ago
  Who runs Neo Store and why do you trust them?
  - escalt 4y ago
    It's just another client that (by default) uses the official F-Droid repo
- wkat4242 4y ago
  There's also aurora droid
autoexec 4y ago
Personally I'm glad that I have to manually confirm updates, but folks who want their apps changed without notice should have the option.
- safety1st 4y ago
  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.

charcircuit 4y ago

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.

aordano 4y ago
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.
- derkades 4y ago
  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.
  - MishaalRahman 4y ago
    Not automatically. It requires the use of a (new in Android 12) API. But you're otherwise right.
- charcircuit 4y ago
  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.
singpolyma3 4y ago
Updates in the background sounds... Bad? Not even play store does that to me.
- Aachen 4y ago
  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.

colordrops 4y ago

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/ https://f-droid.org/en/packages/com.termux.nix/

somat 4y ago

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=20170701170044 https://undeadly.org/cgi?action=article&sid=20230119075627 https://undeadly.org/cgi?action=article&sid=20230119075627

kpcyrd 4y ago
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).

kpcyrd 4y ago

Arch Linux is heavily invested into it: - https://reproducible.archlinux.org/ 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 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 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.