FS#44735 - [minitube] GOOGLE_API_KEY is much too generic to put in user's environment, use a wrapper instead
Attached to Project:
Community Packages
Opened by Alain Kalker (ackalker) - Sunday, 26 April 2015, 07:21 GMT
Last edited by Antonio Rojas (arojas) - Saturday, 19 August 2017, 08:37 GMT
Opened by Alain Kalker (ackalker) - Sunday, 26 April 2015, 07:21 GMT
Last edited by Antonio Rojas (arojas) - Saturday, 19 August 2017, 08:37 GMT
|
Details
Description:
The recent update of minitube 2.4-1 asks the user to edit GOOGLE_API_KEY in /etc/profile.d/minitube.sh with a user-generated API key. Exporting the environment variable GOOGLE_API_KEY means that it is included in the environment of every application the user runs, effectively claiming this very generic name for the sole use of minitube. Please use a wrapper script for minitube to set this variable from some configuration file in the user's $XDG_CONFIG_HOME directory (falling back to $HOME/.config if XDG_CONFIG_HOME is not set). Marking as Severity: High because the current situation could cause serious trouble when using applications which are using this environment variable for other purposes. Additional info: * package version(s) minitube 2.4-1 * config and/or log files etc. Steps to reproduce: |
This task depends upon
Closed by Antonio Rojas (arojas)
Saturday, 19 August 2017, 08:37 GMT
Reason for closing: Fixed
Additional comments about closing: minitube 2.8-2
Saturday, 19 August 2017, 08:37 GMT
Reason for closing: Fixed
Additional comments about closing: minitube 2.8-2
Edit: A quick google search shows that this variable name is pretty commonly used for Google API browser keys. I'm still trying to understand the problem here.
Many applications use environment variables to allow users to force override values in their configuration files, often for debugging and testing purposes.
Using such a generic name for a global environment variable (although that choice is probably more upstream's problem) is just asking for trouble somewhere in the future.
I bet that this is just the tip of the iceberg, Google probably has contracts with external parties allowing them to use any number of private APIs.
https://developers.google.com/api-client-library/python/guide/aaa_apikeys
speps, there is an issue that the notice isn't displayed on first install, only on upgrade.
didn't seem to work, I've spent several hours today digging into the cause.
And I ended up here.
The reason why Chromium wouldn't translate websites for me was that, once upon
a time, I installed minitube and stupidly followed the instructions to export
GOOGLE_API_KEY in /etc/profile.d/minitube.sh using a browser key of mine.
Thus, Chromium didn't use the compiled in API keys that were provided to Arch
Linux by Google, instead using my unprivileged key - resulting in 403s on every
request to translate a page.
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/chromium#n56
https://chromium.googlesource.com/chromium/src.git/+/master/google_apis/google_api_keys.h#27
It took me way too long to figure out that a stray environment variable was to blame for this issue.
So, yes - this is a bug worth fixing. It breaks Chromium features, translate being just the most obvious.
GOOGLE_API_KEY="", which is already enough to break Google API usage in Chromium.
FS#55118, apparently minitube should ask the user for this when needed? (I assume it will then write that info to its own configuration file.)@speps, @arojas, it does seem like this is sort of silly to do via profile.d, and potentially harmful for things like Chromium which allow overriding the baked-in and perfectly usable keys via environment variables (though this seems a bit silly of Chromium too).
FS#55118this is my take on this discussion: You have two options:1. Leave the user to its own devices to go create a personal API key and input it when asked by minitube.
2. Create a *second* YouTube API key using Arch Linux's developer account and compile minitube with such key *embedded* in the executable as explained in here https://github.com/flaviotordini/minitube/blob/master/README.md#build-instructions (that file is included in the tarball).
Would option 2 make everyone happy?