Summary: | www-client/firefox add flag for disabling google api key during build | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Th <info+d1553fd> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | enhancement | CC: | bugs.gentoo.org, jstein, libor+gentoobugs, main.haarp, redblade7, th-gen, tsmksubc |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Th
2017-06-17 09:54:27 UTC
(In reply to Th from comment #0) > I noticed in about:support that the row 'Google Key' says 'found'. After > taking a look into the ebuild-files every ebuild sets an api-key in > src_configure. > > It would be nice to be able to disable the api key during the build-process > with a use-flag. > > Reproducible: Always There is no advantage to disabling it. This would just introduce more breakage from users disabling a feature they expect to work. > # Note: These are for Gentoo Linux use ONLY.
You're inadvertently making it possible for Google to trivially identify and fingerprint Gentoo users. Can't say I approve.
I'm still not willing to put this on a use flag. Builds should however still support EXTRA_ECONF, and so with that you could append --without-google-api-keyfile or --with-google-api-keyfile=/path/to/your/own to configuration in order to override it, without patching the ebuild yourself. However as Jory said, YMMV and you get to pick up the pieces. How about adding a check for an environment variable? If not set, ebuild will set it. We just need to check for a special value to set --without.. or will an empty just disable that feature? (In reply to Thomas Deutschmann from comment #4) > How about adding a check for an environment variable? If not set, ebuild > will set it. We just need to check for a special value to set --without.. or > will an empty just disable that feature? I was thinking that, but, ECONF_EXTRA is a variable too (would be set in the same manner in package.env) and it'll already take care of this. And we are -really- strongly discouraged from allowing random variables in ebuilds from being manipulated by end users.. I found some info about the issue from Seamonkey devs mailing list http://mozilla.6506.n7.nabble.com/Google-API-Key-td281258.html. I am not sure I understand the issue but I think that I am with the Th and I would rather have a build that does not communicate with Google than setting up some magical string somewhere behind my back. I especially agree with http://mozilla.6506.n7.nabble.com/Google-API-Key-td281258.html#message281338: > > People that build their own versions of Firefox can either provide their > > own keys and these services will work... or they can do nothing, and > > these services will not work. > > This is IMHO a big argument to, one by one, try to get rid of using > those services and build on free-to-use alternatives instead. > > Robert Kaiser I would like to have break_google_products_reuiring_api_key USE flag for firefox and seamonkey. That way, no one can complain that they disabled a feature they expect to work. This is now possible add your own or disable usage of Google API key at all via MOZ_API_KEY_GOOGLE. |