[HN Gopher] Towards a Reproducible F-Droid
___________________________________________________________________
Towards a Reproducible F-Droid
Author : mikece
Score : 122 points
Date : 2023-01-20 18:08 UTC (4 hours ago)
(HTM) web link (f-droid.org)
(TXT) w3m dump (f-droid.org)
| ThrowawayTestr wrote:
| I'm surprised reproducibility isn't a bigger deal for the OSS
| community.
| charcircuit wrote:
| 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.
| singpolyma3 wrote:
| Updates in the background sounds... Bad? Not even play store
| does that to me.
| aordano wrote:
| 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 wrote:
| 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.
| codewiz wrote:
| 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/
| codewiz wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Despite the downvotes you are spot on.
| [deleted]
| tgsovlerkhgsel wrote:
| 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
| Ajedi32 wrote:
| 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.
| tgsovlerkhgsel wrote:
| Yeah, I wasn't sure because I hadn't seen any updates in a
| while
| NoahKAndrews wrote:
| Neo Store is an alternative F-Droid client that supports that
| API.
| wolverine876 wrote:
| Who runs Neo Store and why do you trust them?
| escalt wrote:
| It's just another client that (by default) uses the
| official F-Droid repo
| autoexec wrote:
| Personally I'm glad that I have to manually confirm updates,
| but folks who want their apps changed without notice should
| have the option.
| Hizonner wrote:
| [flagged]
| [deleted]
| yjftsjthsd-h wrote:
| > 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.
| notpushkin wrote:
| > 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.
| Hizonner wrote:
| Which means I have to trust them to do that verification
| correctly. Which is the whole problem with them signing the
| APKs in the first place.
|
| On edit: What I meant by "unless something is checking" was
| that something _independent_ had to be checking. Thought that
| was obvious.
| notpushkin wrote:
| 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)
| Hizonner wrote:
| OK, if that's the case I retract everything and
| apologize. I must have misread it. Thank you.
___________________________________________________________________
(page generated 2023-01-20 23:00 UTC)