Closed IzzySoft closed 10 months ago
Hi, sorry for the delay and thank you for helping us to onboard our app to your repository, we've been receiving good traffic (we got almost 30 users in just 1 week). I went through the guide you shared for onboarding the app to F-Droid. I read about reproducible builds and how F-Droid ensures all libraries are open source. I've got a couple of questions related to the same:
<applicationId>.yml
is there a way to specify to use foss-master
branch instead of master for reproducible builds?Glad to read your happy with the listing! Let me help with your questions as well:
foss-<versionName>
(to make them clearly recognizable; keep the prefix constant and use it only for those) and point them to a commit inside that branch.Thank you! I'll plan to submit an issue to F-Droid repo by today
I'll plan to submit an issue to F-Droid repo by today
I'd suggest to consider the order of tasks. If you start that before having this PR merged, issuebot will complain about Fastlane being amiss :wink:
I'll plan to submit an issue to F-Droid repo by today
I'd suggest to consider the order of tasks. If you start that before having this PR merged, issuebot will complain about Fastlane being amiss 😉
Got it, I'll make sure to merge this PR. I have one more question, I have some credentials in .env file, I have just added placeholder values in GitHub and have actual values in my local. Will it affect the reproducible builds in anyway (because apk built in my local will have actual credentials and one from GitHub will have dummy values)?
Will it affect the reproducible builds in anyway (because apk built in my local will have actual credentials and one from GitHub will have dummy values)?
Sure that will affect it. For RB to succeed, the resulting APKs (yours and F-Droid's) must be identical (except for the signature of course). You can get it working nevertheless by providing corresponding APKs in addition to the other one (like, fdroid_build_*.apk
) at the releases, should the ones currently attached be those with "actual credentials".
Will it affect the reproducible builds in anyway (because apk built in my local will have actual credentials and one from GitHub will have dummy values)?
Sure that will affect it. For RB to succeed, the resulting APKs (yours and F-Droid's) must be identical (except for the signature of course). You can get it working nevertheless by providing corresponding APKs in addition to the other one (like,
fdroid_build_*.apk
) at the releases, should the ones currently attached be those with "actual credentials".
So the APK with fdroid_build_*.apk
will have dummy credentials and used for validating RB, and other APK (let's say fdroid_release*.apk
) will be used for releasing, is my understanding correct?
Only the first part. The very same ones used for validating RB would be used for releasing. We can only release what was validated. The others would then be "additional download options at Github".
Just wondering what you're aiming at: Would the app work without proper credentials – or could the one built with "dummy credentials" not be used? What credentials we're talking about anyway?
Currently, I have a Dropbox OAuth password. Its essential for the app to work properly. I believe it's not a sensitive credential and it would be exposed in the APK binary after the compilation anyway. But I think its not best practice to expose it in public repos as it can be used to impersonate other apps.
I will add a proxy server to fetch these credentials instead of storing them in code, so that RB's can produce same result
You could provide a configuration option for that, so whoever wants to use it could provide their own credentials. That would entirely solve that problem (that's what comparable projects did in this case).
Yeah, currently they still need to login to their Dropbox account with their own creds. But setting up the Dropbox Oauth app with right permissions might be a bit tedious, but we can use this for NextCloud which only requires a username and password for authenticationnstead of access tokens. I am working on setting up a proxy server for this, I will update by today.
Thanks! Updated the config for your app on my end, so Fastlane will be pulled along with new releases from now on.
What type of PR is this? (check all applicable)
Description
Your Fastlane "starter package" as discussed in #70. Be welcome to use my Fastlane Cheat Sheet to build on this (e.g. adding per-release changelogs), and take care for the limits (e.g. max 80 chars for shortdesc, max 4.000 for fulldesc, max 500 for per-release changelogs).
Note that for fulldesc I used full HTML compressed to a single line. This is for 2 reasons: formatting looks better, and "no linebreaks" prevents F-Droid from converting each
\n
into a<br>
(yes, it does that) making it look … well, less good :see_no_evil:Featured Covered in this PR
Related Tickets & Documents
Screenshots, Recordings
Part of the PR :see_no_evil:
Tested Feature??