Google has been moving away from this to an approach matching Apple. Developer keys will only be used to verify uploads of bundles used to generate packages signed by the app store.
Amazon and the official F-Droid repository also centralize trust, just without the optimizations.
Conversation
Replying to
F-Droid only does this when the app is not reproducible. They don't want to ship unverified binaries to users, so they build apps themselves. If the build matches the submitted binary, the developer's original binary and signature is shipped.
2
Otherwise they don't know what's in the binary, so they ship their own build, which is then obviously signed by F-Droid themselves.
1
Replying to
In theory, they could do that, but it isn't how they actually do things for their official repository. Since they lag so far behind in adopting the current tooling, it wouldn't work in practice anyway. They'd be unable to ship app updates for years...
Quote Tweet
Replying to @0xjomo
F-Droid ships releases signed with their own keys even for apps with reproducible builds. That's the excuse that's given but it's not what they actually do in practice. Their builds of apps have also had serious issues not present in developer builds such as using legacy tools.
1
Replying to
I just installed Oeffi via F-Droid and it seems to be signed by the developer:
1
Replying to
This what you claim above:
> F-Droid only does this when the app is not reproducible.
This screenshot does nothing to provide evidence for your completely untrue claim above.
F-Droid shipping apps signed by the developers is a rare exception, not the common case for them.
1
It took F-Droid 5 years to adopt v2 signatures, which was an important security fix for the signing system.
F-Droid lags years behind in using the current tooling and technologies.
It's unreasonable to expect app developers to stick to legacy tooling so that this can work.
1
Replying to
> This screenshot does nothing to provide evidence for your completely untrue claim above.
Well I wasn't trying to provide "evidence" ;
1
The point I was trying to make earlier is simply that F-Droid supports – to some extent at least – reproducible builds, therefore not necessarily breaking the decentralized trust. Your tweet didn't mention that, so I wanted to add that.
1
1
They might not automatically do it and there be some issues with it, but you make it sound like they don't support it at all, which doesn't seem to be the case, is it?
2
Replying to
> F-Droid only does this when the app is not reproducible.
This is the initial claim you made. The claim is false. The vast majority of apps packaged by F-Droid are simply built and signed by them without ever attempting to use the developer builds. There are rare exceptions.
twitter.com/0xjomo/status/
You claimed that they only ship their own builds signed with their keys when the upstream project lacks reproducible builds. This description of what you claimed doesn't match what's actually posted above at all and the initial claim is not at all true.
Quote Tweet
Replying to @0xjomo and @DanielMicay
The point I was trying to make earlier is simply that F-Droid supports – to some extent at least – reproducible builds, therefore not necessarily breaking the decentralized trust. Your tweet didn't mention that, so I wanted to add that.
1
There are more than minor issues with the system they use for it in the rare cases where they actually do it. It's essentially something new and lacks a history of it working out. They've historically had major issues keeping apps updated, even without this as a blocker for it.