Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reproducible builds #1264

Open
rugk opened this issue Jun 15, 2021 · 9 comments
Open

Reproducible builds #1264

rugk opened this issue Jun 15, 2021 · 9 comments

Comments

@rugk
Copy link

rugk commented Jun 15, 2021

Please use GitHub reactions 👍 to show that you are affected by the same issue. Please don't comment if you have no relevant information to add!

Is your feature request related to a problem? Please describe.

Faster updates from a trusted F-Droid repository.
And reproducible builds are also very good for security reasons: See https://reproducible-builds.org/.

i unfortunately can't provide a quicker way to test new approaches than the release cycle of F-Droid allows

#1256 (comment)

Technically you could if the builds are reproducible you can sign both the same APK with your key and F-Droid just distributes that.

Describe the solution you'd like

F-Droid's reproducible builds.

Describe alternatives you've considered

Additional context

The people at CCTG and Signal (IIRC) e.g. made it work, so you can built on their experience: https://codeberg.org/corona-contact-tracing-germany/cwa-android/src/branch/main/docs/rebuilding.md

It's basically a Docker image with F-Droids buildserver.

Note: Yes, I know it's likely not easy to setup, but it is a good idea for the future. 😊

@stefan-niedermann
Copy link
Member

If you are suggesting to setup an own F-Droid repository: No, i have answered this already on help.nextcloud.com.

Technically you could if the builds are reproducible you can sign both the same APK with your key and F-Droid just distributes that.

This requires still waiting for an index update of F-Droid. The build time itself is not the issue, but the time of the index update. Therefore this will not speed up the rollout of the app on F-Droid.

Am i missing something here?

@rugk
Copy link
Author

rugk commented Jun 19, 2021

The build time itself is not the issue, but the time of the index update. Therefore this will not speed up the rollout of the app on F-Droid.

No, AFAIK, one could install the app from F-Droid, and then switch to the installed app from your source (if it is no F-Droid repo, even a simple APK attached at GitHub releases would be sufficient e.g.). The advantage then is testers could just get your APK before it is built by F-Droid, as it is signed with the same key.
I know I did this for CCTG, so I know it technically works. 🙂

@stefan-niedermann
Copy link
Member

I don't fully understand - even if F-Droid would accept a build of mine as equal and ship it, Android would prevent one from installing it over an already installed version due to a signing key mismatch...?

as it is signed with the same key.

In fact it isn't the same key though, is it? - F-Droid signs with its own key, while apk files build by me are signed with my key, even if the builds are the same...

@rugk
Copy link
Author

rugk commented Jun 21, 2021

You sign it with your own key, F-Droid builds the same binary and verifies it is identical and if so,. distributes your binary.
That is one way, AFAIK. That’s the whole clever idea of that. 🙂

I hightly suggest reading https://f-droid.org/en/docs/Reproducible_Builds/, especially the “How it is implemented as of now” part.

Edit: FYI here is e.g. an example reproducible build AFAIK, from admin-ch/CovidCertificate-App-Android#40 (comment)

@stefan-niedermann
Copy link
Member

So what exactly needs to be done on our side? As far as i understand, we would need to setup a production build pipeline (currently only dev build) which would require us to place the signing key on as a variable on the CI runner (GitHub in this case).
Since i don't trust GitHub i am not willing to push my private key as a secret variable there. Neither do i have the capabilities to setup and maintain an own build server.

Am i missing something? Don't get me wrong, reproducible builds are a fine thing, though i can't see how we should solve this predicament...

@rugk
Copy link
Author

rugk commented Oct 6, 2021

As far as i understand, we would need to setup a production build pipeline (currently only dev build) which would require us to place the signing key on as a variable on the CI runner (GitHub in this case).

Hmm, you don't need to do that?
Respectively, if you have not already done that before, you don't need to. You can just build the same way as you did before.
You "just" need to make sure the build itself is reproducible and then the F-Droid server does it for you. Okay, you also need to upload your release artifact (APK) somewhere, where the F-Droid server can find it.

But I can also point to the FAQ and docs above and am no expert here. Maybe @IzzySoft can help?

@IzzySoft
Copy link

IzzySoft commented Oct 6, 2021

Sorry, but I can't – I'm not a dev and not familiar with how to set up reproducible builds.

@stefan-niedermann
Copy link
Member

Well i read the docs but i need more exact instructions regarding the steps to do. "Build your APK locally and upload it anywhere the F-Droid server can find it" is unfortunately not preceise enough for me to get this done...

@IzzySoft
Copy link

IzzySoft commented Oct 6, 2021

Ah, that part I can answer. Let me cut it into pieces:

  • "Build your APK locally": ideally using the same tool chain (fdroidserver) so the resulting APK is binary identical to what F-Droid builds – apart from the signature (you will need to sign this APK with your key)
  • "upload it anywhere the F-Droid server can find it": it must be publicly available, i.e. F-Droid must be able to access it
  • the piece you're probably missing: that URL then needs to be added to the build block in F-Droid's *.yml. And it should carry the versionCode in it's name, so it's easily matched – like org.example_<versionCode>.apk which then would be referenced as org.example_%c.apk and the %c would then always be replaced by the versionCode of the current build.

Does that help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants