3 ms·

good point; have updated the blog post.

by Arathorn 6y ago

cxr 6y ago
> We're also looking into running our own F-Droid repository going forwards That's great to hear as well.
- khimaros 6y ago
  i disagree. the main repository enforces reproducible builds and restricts trackers. please keep the main repo up to date.
  - sneak 6y ago
    The main repository also signs everything with f-droid keys, not the original developer's. This means any compromise in f-droid compromises everything.
    - khimaros 6y ago
      sounds like a problem to solve. build in both places, verify build hashes agree, upstream dev infra signs and sends signed build to f-droid, f-droid verifies hash against its own build, verifies upstream signature, signs and then lists. apks can have more than one signature.
    - khimaros 6y ago
      actually, it turns out this is no longer a limitation: https://f-droid.org/docs/Reproducible_Builds/ https://f-droid.org/docs/Reproducible_Builds/ "Publishing signed binaries from elsewhere (e.g. the upstream developer) is now possible after verifying that they match ones built using a recipe. Publishing only takes place if there is a proper match."
  - cxr 6y ago
    Well, I disagree with your disagreement. Part of the value of F-Droid is that the main repository can host packages that are vetted and maintained by uninvolved parties. Second, if the Matrix-run repository does reproducible builds, then... there's no problem. (That's the nature of reproducible builds.) Third, F-Droid was conceived to be distributed and decentralized. That's why it allows you to add other sources in the first place, there's even a feature baked in that lets you get/share apps (including F-Droid itself) in-person with people around you, and under the hood the whole thing uses a DVCS-style model where the package index is "dead" data and your device manages a copy. Fourth, an app author choosing to run their own repository means that they're invested in F-Droid, moreso than instances where F-Droid's role is to achieve "mere availability" for the package. What's more, this incident is evidence that we need more decentralization, not less. In instances where decentralization is either already working or is up for consideration, we should encourage it, not try to eradicate it.
    - xorcist 6y ago
      If they provide reproducible builds there's also no need for a separate repository.
      - cxr 6y ago
        Can you explain your reasoning?
Cyphase 6y ago
FYI, unless you're providing reproducible builds to F-Droid signed by your key (which doesn't seem to be the case), that APK is going to be signed with a different key. So it's either uninstallable over top of a Play Store-derived APK, or if someone does install it who doesn't currently have Element installed, they won't be able to install a Play Store-derived APK later – at least not without uninstalling first, and unless they do that with the right adb option, they'll lose any app data they have. Ideally you could set up reproducible builds and make sure that the version in the default F-Droid repo stays up-to-date, but reproducible builds may not be practical for you right now (I'm not sure). Barring that, as you mentioned in the blog post, setting up your own F-Droid repo with self-signed APKs is a good option. I haven't yet played with Matrix nearly as much as I would like, but I love the vision. Thanks for your efforts! Also nice plug for F-Droid; they're doing good work as well.

good point; have updated the blog post.

cxr 6y ago

> We're also looking into running our own F-Droid repository going forwards That's great to hear as well.

khimaros 6y ago
i disagree. the main repository enforces reproducible builds and restricts trackers. please keep the main repo up to date.
- sneak 6y ago
  The main repository also signs everything with f-droid keys, not the original developer's. This means any compromise in f-droid compromises everything.
  - khimaros 6y ago
    sounds like a problem to solve. build in both places, verify build hashes agree, upstream dev infra signs and sends signed build to f-droid, f-droid verifies hash against its own build, verifies upstream signature, signs and then lists. apks can have more than one signature.
  - khimaros 6y ago
    actually, it turns out this is no longer a limitation: https://f-droid.org/docs/Reproducible_Builds/ https://f-droid.org/docs/Reproducible_Builds/ "Publishing signed binaries from elsewhere (e.g. the upstream developer) is now possible after verifying that they match ones built using a recipe. Publishing only takes place if there is a proper match."
- cxr 6y ago
  Well, I disagree with your disagreement. Part of the value of F-Droid is that the main repository can host packages that are vetted and maintained by uninvolved parties. Second, if the Matrix-run repository does reproducible builds, then... there's no problem. (That's the nature of reproducible builds.) Third, F-Droid was conceived to be distributed and decentralized. That's why it allows you to add other sources in the first place, there's even a feature baked in that lets you get/share apps (including F-Droid itself) in-person with people around you, and under the hood the whole thing uses a DVCS-style model where the package index is "dead" data and your device manages a copy. Fourth, an app author choosing to run their own repository means that they're invested in F-Droid, moreso than instances where F-Droid's role is to achieve "mere availability" for the package. What's more, this incident is evidence that we need more decentralization, not less. In instances where decentralization is either already working or is up for consideration, we should encourage it, not try to eradicate it.
  - xorcist 6y ago
    If they provide reproducible builds there's also no need for a separate repository.
    - cxr 6y ago
      Can you explain your reasoning?

Cyphase 6y ago

FYI, unless you're providing reproducible builds to F-Droid signed by your key (which doesn't seem to be the case), that APK is going to be signed with a different key. So it's either uninstallable over top of a Play Store-derived APK, or if someone does install it who doesn't currently have Element installed, they won't be able to install a Play Store-derived APK later – at least not without uninstalling first, and unless they do that with the right adb option, they'll lose any app data they have. Ideally you could set up reproducible builds and make sure that the version in the default F-Droid repo stays up-to-date, but reproducible builds may not be practical for you right now (I'm not sure). Barring that, as you mentioned in the blog post, setting up your own F-Droid repo with self-signed APKs is a good option. I haven't yet played with Matrix nearly as much as I would like, but I love the vision. Thanks for your efforts! Also nice plug for F-Droid; they're doing good work as well.