Closed dimqua closed 4 years ago
@st3fan What about them build flags, though? (You seem to be the only Mozilla employee who has replied here.)
Same advice as https://github.com/mozilla-mobile/fenix/issues/12809#issuecomment-663006957
That thread is more about the usage of (third-party) SDKs and Mozilla services, but the same applies.
That said, I don't know how to solve the "Mozilla Maven" problem. We take some really big dependencies from there like GeckoView and Android Components. You can definitely build those from source, but that is not a small job.
That said, I don't know how to solve the "Mozilla Maven" problem.
Mozilla maven could be added into trusted repos just as Google Maven does, as long as there are only open source libs.
@Rudloff @Bubu See https://github.com/mozilla-mobile/fenix/issues/12809#issuecomment-663006957.
How much additional space does the Firefox Account Sync functionality take? (I think it's App Services or 'AS', the third component after AC and GV in About Firefox?)
If it is of any benefit (like reduced app size), then maybe there could be a build variant which comes without this functionality for those (like me) who don't use a Firefox account.
Hi all, I'd like to see Fenix in F-Droid but I don't want any functionality removed, like account syncing. Cheers 🙂
Hey all!
I wanted to look at the list of requirements to get Fenix into f-droid.
The problem here is that our policy only allows dependencies built from source or fetched from a trusted repository. Fenix uses dependencies from https://maven.mozilla.org/, which is not in our whitelist. We decided not to add Mozilla's repository to the list because they have included non-free dependencies like Play Services in their builds in the past.
I do not understand how this is different to other repositories in the whitelist. jcenter, maven central, they all contain artifacts that may link against google play services or others. We did publish our own artifacts to jcenter at some point, but that caused a ton of (technical) issues and that's why we've set up our own repository.
So the solution to this would be for us to build these dependencies (mostly android-components) entirely from source, but this could be a lot of work. (And some of these components also use custom repositories and non-free dependencies...)
We can probably entangle that at the Fenix level. However I still wonder why for Fenix everything needs to be build from source, while this doesn't seem to be the case for other apps on f-droid?
We should be able to provide build flags that lets f-droid (or anyone else) build Fenix without the mentioned libraries. But if building the whole tree from source is something that is required, then this would be up to f-droid.
@pocmo Agreed with your statements.
Though, if whitelisting Mozilla's maven repository isn't an option for some reason, note that I've been able to build Fenix and its main dependencies from source this week-end, without relying on Mozilla's maven repository and removing any non-free requirement I found on the way. I made a tiny build script that automatically applies the required patches and runs the build in docker. I might share it if it's useful at some point or if it gets some interest.
Here are the main steps to follow to achieve this:
localMaven()
to any repository{}
declarationGecko.kt
and lib/crash/build.gradle
)If we can't come to a simpler solution that would allow Fenix to be included in F-Droid's main repo, I'll probably create my own F-Droid repository that provides automated free builds of Fenix.
In any case, having a build variant of fenix that doesn't include play-services-oss-licenses, mozilla-lib-push-firebase and google-ads-id dependencies and therefore doesn't import them wouldn't be a waste of time. It would at very least prevent the maintainer (be it third-party or F-Droid team) from applying dirty patches manually that may often break the build.
(although the play-services-oss-licenses plugin is itself open-source, the play-services-oss-licenses library isn't and includes dependencies to the play services)
There is an open source alternative to this that the developer of Tachiyomi recently used to replace it: https://github.com/ligi/ThirdPartyLicenseDisplay
@gilbsgilbs
If we can't come to a simpler solution that would allow Fenix to be included in F-Droid's main repo, I'll probably create my own F-Droid repository that provides automated free builds of Fenix.
This seems like the better solution, doesn't it? Slightly more work, yes, but getting all unessecary dependencies and anti-features completely out of the build would be ideal, no? As long as it could be maintained properly long term, I would be +1 for this.
@gilbsgilbs I wonder - would be willing create bugs on bugzilla.mozilla.org or at https://github.com/mozilla-mobile/fenix/ for these issues and possibly for some low-hanging fruits, send them patches? It would be great if everyone could benefit, even GPLAY users..
In any case, having a build variant of fenix that doesn't include play-services-oss-licenses, mozilla-lib-push-firebase and google-ads-id dependencies and therefore doesn't import them wouldn't be a waste of time. It would at very least prevent the maintainer (be it third-party or F-Droid team) from applying dirty patches manually that may often break the build.
Tor will likely be working with Mozilla on getting some of these changes upstreamed into Fenix for Tor Browser, so hopefully there will be an official build variant like this in the future (of course, I can't make any guarantees about when/if this will actually happen, or to what extent it will be successful, but we'll see).
note that I've been able to build Fenix and its main dependencies from source this week-end, without relying on Mozilla's maven repository and removing any non-free requirement I found on the way.
Nice, that must have been a lot of work - including building all the Rust code.
In any case, having a build variant of fenix that doesn't include play-services-oss-licenses, mozilla-lib-push-firebase and google-ads-id dependencies and therefore doesn't import them wouldn't be a waste of time. It would at very least prevent the maintainer (be it third-party or F-Droid team) from applying dirty patches manually that may often break the build.
Agree, I think that's something that makes sense to have at the Fenix level and land as build flags here.
@pocmo
Agree, I think that's something that makes sense to have at the Fenix level and land as build flags here.
How do you think this should be done though? I'm not a gradle expert at all, but I feel like Fenix build configuration is quite complex already and relying on build flavors and/or build types to exclude these dependencies would induce a lot of rework on CI scripts, taskcluster and stuff isn't it? I don't feel like it's something somebody completely foreign to Mozilla could do (or some pointers would be appreciated :smiley: ). But it surely would be safer to have the OSS variant included in the CI process.
Or maybe what you meant with "build flag" is a project property that would exclude proprietary dependencies with basic if
s? This way, we would build the free variant of fenix like: gradle assembleGeckoProduction -Porg.mozilla.fenix.isOss=true
and proprietary junk would just be "ignored"?
Lastly, setting up the build configuration is one thing, but how would it work in the code? I think F-Droid requires not only the final build artifact to only involve free software, but also the whole build process. How to deal with proprietary imports then? The only solutions I see involve using reflection which doesn't sound very safe (though it could be mitigated by working with gradle build sources and by using some reflection library like jOOR). I'm sure other F-Droid projects have already dealt with this in the past, I'm curious how they did and/or if anybody have better ideas than mine.
I have to say I'm a bit reassured that Mozilla is still open to have such variant of Fenix. I was (and still am) worried that Fenix includes and enables by default so many different spying libraries (and even proprietary ones) without collecting any form of user consent. At least making progress on this issue will provide a better alternative to users who really care about their privacy :+1: .
@gilbsgilbs Again, I personally would highly like to see a build with all the junk completely removed rather than just ignored, I think this would be the ideal option from a philosophy stance, even if a bit more work it would please many more users. It's a shame we even need an independent build like this when Firefox is supposed to be "privacy friendly" but this is simply not true. The amount of data reporting, phoning home, telemetry, etc is absurd where it would simply be amazing to be able to have an fdroid build with all this removed instead of just ignored.
I do understand this would be a bit more work, but if someone can do it that'd be amazing. As for how to best do it, I unfortunately am not knowledgable enough to help with that.
@grravity "Ignored" here means ignoring the proprietary part of the code while building, so that it wouldn't be included in the apk.
Yeah yeah, in case it wasn't clear, "ignored" means that you don't even fetch them to build fenix. That's why I talked about imports and reflection: if you don't have the libraries locally, you can't build any code that import those libraries.
To be clear, I already have a local, rebranded fork of fenix without the proprietary libraries, without the trademarked name and logo, and with tracking disabled by default. But having everything we can being officially supported would just be better for everyone. I want to see how things evolve before making it publicly available.
Hi all,
I would like to add that I don't subscribe to the conspiracy theory that Mozilla is secretly tracking every one of it's users (telemetry and crash reporting is not tracking). Nor am I such a hardcore FLOSS fan that I can't stand any non-FLOSS code... after all, we're using GitHub here, which isn't FLOSS! However, I definitely would like to see Fenix available on F-Droid, ideally as an official Mozilla build, because that's one less app which I need to rely on Google Play for, and the less dependence I have on Google (or any other single "big tech" company) the better.
Cheers 🙂
@gilbsgilbs Yes, I was thinking about gradle properties that can be used as flags on the command line or in local.properties
.
Regarding the imports etc.: I was thinking we could use the same approach as Fennec. For example it hides "Leanplum" behind MmaDelegate
. All Fennec code only calls methods on MmaDelegate
. Internally MmaDelegate
uses (based on build configuration) either MmaLeanplumImp
or MmaStubImp
.
@opusforlife2 Ah, I misinterpreted, understood. Sorry
@gilbsgilbs Thank you so much for working on this! ❤️
I've opened #13453 which implements an OSS build flag for fenix. I think this should be enough to close this issue (as the only real blocker to having fenix into F-Droid would be whitelisting Mozilla's maven repository which is mostly political at this point). Let me know what you think @pocmo .
@gilbsgilbs
If we can't come to a simpler solution that would allow Fenix to be included in F-Droid's main repo, I'll probably create my own F-Droid repository that provides automated free builds of Fenix.
Thanks for all your work toward a FOSS build of Fenix! If you do host your own F-Droid repo with a "Fenix FOSS" or whatever you may call it... as a side note, could you also include support for about:config? Should be available in source since it is enabled in Fenix Beta and Nightly.
Sorry if this is the wrong place to ask this. Again, thanks!
As I closed the initial PR to split it into smaller chunks, I'll keep track of the progression of the different PRs in this comment:
play-services-oss-licenses
library:
F-Droid dev here. I've been working on Fenix inclusion for the past couple of months. Here is a recipie and a set of scripts. In short, it eliminates Mozilla Maven repository and builds GeckoView, Glean, Android Components and Application Services from source (without proprietary components). Fenix itself is heavily patched to remove non-free stuff; the removal of play-services-oss-licenses and flags for other proprietary dependencies are very appreciated, @gilbsgilbs.
Fenix F-Droid is still a work-in-progress, but all the heavy lifting is done and it will eventually replace the old good Fennec F-Droid. Thanks to everyone working on this task!
* [ ] Remove `play-services-oss-licenses` library: * [x] PR done #13767 * [x] PR approved * [ ] PR merged
@gilbsgilbs #13767 was merged.
@relan sorry I probably missed this discussion - but what was the reason again that you can't depend on our Maven repo? Is there anything we can do?
what was the reason again that you can't depend on our Maven repo?
Nothing specific to the Mozilla repo. F-Droid aims at building everything from source to make sure that binaries correspond to the source code. Currently we allow some widespread repositories like Maven Central, JCenter, JitPack, etc. but in the future we'd like to get rid of this legacy.
Is there anything we can do?
My wishlist :) to all upstream developers:
Just wanted come by here and say that there is a fork of Fenix, and the developer is trying to get it in F-Droid https://github.com/interfect/fenix/issues/26. @relan you might be interested
Meanwhile, another proprietary library (com.google.android.play:core) was added in 365d1019f6ee7c28a2824a80506d74977983544b. :disappointed:
Was it added with a build flag to exclude it?
If not, is this something the Fenix team could take care to keep in mind for the future? Proprietary dependencies should be added with a build flag so that it is easy to build a free flavour without them.
Edit: (at least, that's the impression I've got from the conversation above.)
FYI, I'm not able to keep up with my work on the build flags just yet. If somebody wants to push #13857 forward, I'll happily give write access to my repo or they can open their own PR. If not, I'll probably come back to it at some point.
Looks like there was an ongoing MR that got merged recently: https://gitlab.com/fdroid/fdroiddata/-/merge_requests/7448
@relan I thank you so much for the hard work.
the F-Droid repo still offers the old version 68.12.0
https://f-droid.org/en/packages/org.mozilla.fennec_fdroid/
I've created a PR to update it https://gitlab.com/fdroid/fdroiddata/-/merge_requests/7462
I have no idea how to say this eloquently, but I believe Fennec should be archived and Fenix should be a new package.
@pwd-github If I am not mistaking, making Fenix a new package would disallow Mozilla to provide it as an update from fennec through Play Store.
F-Droid does not want to have it auto update for some reason.
"The app shares the appid with the official F-Droid Fennec build but is signed with a different key, so it won’t install as an update to any existing version and neither will the future official build install over this version."
https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113/16
F-Droid does not want to have it auto update for some reason.
Well, to be clear, the Fennec will share the same signing key as the old one (and all F-droid apps). Only a temporary test key for the test version.
F-Droid does not want to have it auto update for some reason.
"The app shares the appid with the official F-Droid Fennec build but is signed with a different key, so it won’t install as an update to any existing version and neither will the future official build install over this version."
https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113/16
Non correct. This only concerns the test build posted by bubu. F-Droid will build and sign and the app will update as usual. https://forum.f-droid.org/t/welcome-a-new-fennec-f-droid/11113/44
@pwd-github If I am not mistaking, making Fenix a new package would disallow Mozilla to provide it as an update from fennec through Play Store.
Surely creating a new package just makes all the sense. Especially given the drastic UI change the limited add-on support. Move Fennec to F-Droid Archive and support org.mozilla.fenix-fdroid in the main repo.
It would be great to keep the Fennec name as it is, due to the reputation that this build variant gained over the years and as mentioned here.
Adding fenix as a tag would be enough.
@relan Firefox does not allow turning off the google safe browsing feature on mobile. Will Fennec-Fenix allow this?
This should be closed https://f-droid.org/en/packages/org.mozilla.fennec_fdroid/
This should be closed
I think this checklist is still important to achieve. https://github.com/mozilla-mobile/fenix/issues/162#issuecomment-674378939
@relan seemed to appreciate the benefits.
This shipped. Thanks to @relan and anyone else involved with the f-droid Fennec/Fenix project. It is better to track tasks about upstreaming any useful code in new issues. This one is far too messy to be of much use.
Would be nice to have this browser available in the F-Droid repository, when it'll be released (I hope soon). That's why I should ask, do you support this idea?
┆Issue is synchronized with this Jira Task