Signal's definition of "reproducible" meant for quite a while "download this binary docker image and build Signal inside of it". I don't know if that has changed since.
Signal rejects F-Droid for a different reason, though: They only want to distribute through channels where they get download statistics and control update rollouts.
I'm not sure what sort of "control" they have over the Play Store compared to f-droid, but I'd rather have a trusted 3rd party do the building transparently and verifyable.
F-Droid uses a package maintainer-esque process where the maintainers of F-Droid can intervene and prevent an update to an app from reaching users if it's deemed to be malicious or to add anti-features.
It's of particularly high need on mobile since popular apps, even those who were originally FOSS, are sold to scummy publishers who fill it with ads and subscription schemes (oft called anti-features, since removing them could be seen as a feature in and of itself), ruining the original. You can't really trust mobile app devs because the track record is downright awful. Recently that happened with the "Simple" collection of apps, where the Play Store version got filled with junk but the F-Droid maintainer froze the version and marked the apps as outdated since nobody could conceivably want the new versions.
Of course, that strokes poorly with developers who a. don't want to deal with potential third parties in their distribution chain rejecting their updates or b. are planning to add anti-features to their apps later down the line. With signal, I'm gonna guess it's mainly a; the Play Stores checks and balances are much less invasive than the sort of thing an F-Droid maintainer might check for. (As I understand it, Google Plays checks mostly are anti-exploit and keyword scans.)
> where the maintainers of F-Droid can intervene and prevent an update to an app from reaching users if it's deemed to be malicious
That sounds like a feature you want when using FOSS.
Imagine distros wouldn't have been able to intervene quickly and malicious xz would be still deployed through their channels just because the authors want to.
Oh yeah, it's an absolutely wonderful feature. F-Droid is pretty much the main app store I'd recommend to get "the basics" from if you're ever in the unfortunate position of having to manage the mobile devices of family members. Having a maintainer "on the lookout" gives so much peace of mind. Not suddenly having the gallery app turn into a data collection machine and baiting less tech-savvy people into vaguely defined subscriptions is a value that's too good not to pass up on.
FOSS isn't really the important part for me there; it's nice, but the real value is that F-Droid is pretty much the only app store that has some reckoning on how the relationship between mobile devs and mobile customers should be far more adversarial than on any other platform due to the poor track record of mobile devs and empowers users to be able to deal with that in a way that restores some degrees of trust.
It's a fucking shame there's not an equivalent on iOS where you can just say "yeah, what you find here can be trusted" and then not have that gets polluted a year down the line. Apple used to somewhat police the App Store back in the early 2010s for similar peace of mind, but that's not the case anymore.
> With signal, I'm gonna guess it's mainly a; the Play Stores checks and balances are much less invasive than the sort of thing an F-Droid maintainer might check for. (As I understand it, Google Plays checks mostly are anti-exploit and keyword scans.)
It might have been b as well – Signal did keep their server code proprietary for many months to add their custom cryptocurrency to it, and added this cryptocurrency for microtransactions into the app as well. There may be many more features like this planned, some of which F-Droid might oppose.
F-Droid with reproducible builds signed by both parties seems the best of both worlds to me, now I don't understand why Signal is so stubborn about this.
> This way F-Droid could potentially insert a backdoor in an update.
Google requires app developers on play store to give goole the keys that enable google to insert backdoors in any release. I can't trust anything on the play store for this reason. There is no way to tell which apps have been backdoored by google for whatever reason (the usual reason is a NSL).
running all my homelab / private repos off of a tiny gitolite3 server, and i'm always amazed that it all runs on an alpine linux VM that uses 75mb of RAM.
for anything even just sharing with friends or whatnot i won't recommend it though, people do love their web-UI and having to explicitly give someone access can turn off people already.
You might need to use another user if you want to set its shell to `gitolite-shell username` (no command= for password authentication) but then you'd need to chain sudo or something to have Gitolite run under its own user again... Seems very tricky.
Or maybe you can write a shell that runs a gitolite-shell command is its arguments are not already gitolite-shell?
I bet in the majority of cases, there's no need to pressure for merging.
In a big company it's much easier to slip it in. Code seemingly less relevant for security is often not reviewed by a lot of people. Also, often people don't really care and just sign it off without a closer look.
And when it's merged, no one will ever look at it again, other than with FOSS.
An insider could just be tasked to look for exploitable vulnerabilities in existing code and compile this information for outside entities without ever having to risk inserting a purpose-made backdoor. Considering the security state of most large codebases, there would be a bottomless well of them.
I've read about workplaces that were compromised with multiple people - they would hire a compromised manager, who would then install one or two developers, and shape the environment for them to prevent discovery, which would make these kind of exploits trivial.
There's a gazillion nice python SSGs but when it comes to advanced stuff like responsive imagrs, i18n or js optimization, you always have to add it yourself.
It seems most of these never became fit for use for some bigger website.
reply