Hacker News Reader

Comment by m-p-3 | Hacker News Reader

Still haven't received the up-to-date version from F-Droid, which is still stuck at 1.2.0. They really should have some provision to expedite a release when a serious security flaw is discovered.

Not the Matrix team's fault, but still a bit worrying. Maybe they could implement their own F-Droid repo to skip the F-Droid build server?

View on HN

F-Droid do the builds rather than Element (or other Matrix client vendors), so the whole thing is at the mercy of the F-Droid CI process. The Element Android build has entered the queue apparently, but not landed yet. We alerted the F-Droid team last week to prepare for the release, but beyond that there's not much we can do.

I understand that it's out of your control, and you even gave them a heads-up. Thank you for your work :)

Have you thought about hosting your own F-Droid repository, like NewPipe does?

https://newpipe.net/#download

F-droid is a blessing and a curse. Many devs experience this 'F-droid catching up with releases' due to the manual signing process. The userbase is always confused about that. Reproducible builds are claimed to be the possible solution but almost nobody is doing that due to the complex setup.

Are reproducible builds the solution? Seems like the fdroid folks would still have to build ("reproduce") the apk to verify that it matches the one provided by the developer. Then they'd sign it and distribute the double-signed apk.

I was under the impression that reproducible builds guard against the "fdroid build servers got compromised" attack vector, (or "developer got compromised", as compared to dev-signed releases) and nothing else.

My understanding is that the level of trust toward the build server can change.

Currently, most things are signed by F-Droid, so distributed building is harder. But later less trusted servers could build the apps and check, leading to a consensus system.

If a project maintained reproducible builds, then they can have the best of both worlds: their own repo where they can publish builds as they like, then f-droid.org can later reproduce them and use the upstream developer's signature.

Or they could coordinate with the F-Droid packagers, like they did for other distributions. (Actually they might have, since they don't exhaustively list them)

Element did coordinate with the F-Droid packagers on behalf of both Element Android and SchildiChat.

Because F-Droid runs their own builds and requires published source code, there is no mechanism for pre-building and staging security releases for issues which are not yet publicly disclosed.

That said, the packager was extremely helpful and prepared the metadata updates in advance to ensure that both applications could enter the build queue as quickly as possible upon release:

- Element 1.2.2: https://gitlab.com/fdroid/fdroiddata/-/commit/76c8f5b87aa8df...

- SchildiChat 1.2.2.sc43: https://gitlab.com/fdroid/fdroiddata/-/commit/232b316f8affe0...

> Because F-Droid runs their own builds and requires published source code, …

That seems… completely reasonable for distributors of open-source projects. Mandatory, even, for compliance many open-source licenses. Are you saying there are other open source repositories (e.g. Linux distros) which would not require published source code before distributing binaries?

I wouldn't go that far. What I meant is more that Element would've been willing to share our private source tree for Element Android 1.2.2 with F-Droid several days in advance of disclosure, if it meant that they could pre-build the binaries and have them ready to ship the moment that the source was made public.

(After verifying that the public source is identical to the privately shared copy, of course.)

Do you need a full source tree for this ? IIRC major Linux distros do this via preliminary disclosure to a private mailing list possibly with a patch attached.

That way distros can do a local build to verify the patch works and fixes the issue & they then apply the patch in their public infra right after the embargo runs out.

This patch workflow would also work with F-Droid. I don't know of any other workflows for this situation.

The fdroid maintainers are... Less than competent. I recommend anybody not to use the main repo at all if they care about security, as any update could take weeks to arrive.

Probably they are just overworked and understaffed. Possibly also lacking money for more/beefier build-servers?

F-Droid maintainers are solely a volunteer effort. The CI helps a lot. The biggest slowdown in the chain is the manual offline signing step.

You can see here the history https://gitlab.com/fdroid/fdroiddata/-/commits/master/metada...

You can donate to support them here https://opencollective.com/f-droid or here https://liberapay.com/F-Droid-Data

That's a bold claim to make without something to back it up; care to share what warrants a rating of incompetent?

The maintainers aren't really the problems - it's their, long and silly build process + schedule. Updates are _always_ at least three days behind, because their build schedule is set in stone and they refuse to change it.

Reply on news.ycombinator.com