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
Task Type Feature Request
Category Packages
Status Closed
Assigned To Antonio Rojas (arojas)
speps (archspeps)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

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
Comment by Doug Newgard (Scimmia) - Sunday, 26 April 2015, 16:18 GMT
And how, exactly, could this cause "serious trouble" for other applications. What in the world would that variable be used for other than a Google API key?

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.
Comment by Alain Kalker (ackalker) - Sunday, 26 April 2015, 16:28 GMT
There isn't 'a' Google API, nor is there 'a' Google API key. There are dozens, maybe even hundreds of Google APIs, many of them requiring authentication using keys.

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.
Comment by Doug Newgard (Scimmia) - Sunday, 26 April 2015, 16:31 GMT
  • Field changed: Task Type (Bug Report → Feature Request)
  • Field changed: Status (Unconfirmed → Assigned)
  • Field changed: Severity (High → Low)
  • Task assigned to speps (archspeps)
Remarking as low severity because there doesn't seem to be an actual problem here.
Comment by Alain Kalker (ackalker) - Sunday, 26 April 2015, 16:33 GMT
Here is a list, if you're curious: https://developers.google.com/apis-explorer/#p/

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.
Comment by Doug Newgard (Scimmia) - Sunday, 26 April 2015, 16:41 GMT
Yes, there are a lot of APIs, but only 4 API keys as far as I can tell, and the current variable is commonly used for the browser key.
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.
Comment by Sean Rand (srand) - Thursday, 04 May 2017, 23:44 GMT
Wow. So after several years of accepting that Chromium's translation feature
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.
Comment by Sean Rand (srand) - Monday, 15 May 2017, 21:21 GMT
By the way, I didn't realise it at the time - but just installing minitube exports
GOOGLE_API_KEY="", which is already enough to break Google API usage in Chromium.
Comment by Eli Schwartz (eschwartz) - Sunday, 13 August 2017, 03:01 GMT
From  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).
Comment by Vorbote (vorbote) - Sunday, 13 August 2017, 13:11 GMT
As initial reporter of  FS#55118  this 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?

Loading...