maxice8
commented
5 years ago That would be too much work for no benefit at all, most distros keep them in public and just rely on people following their advice
Closed pobetiger closed 5 years ago
maxice8
commented
5 years ago That would be too much work for no benefit at all, most distros keep them in public and just rely on people following their advice
System
Expected behavior
These two packages when build using ./xbps-src automatically includes the google api keys assigned to Void Linux. It should probably be defaulted to off.
See Heads mozilla.dev.planning listserv: https://stackoverflow.com/questions/53552583/whose-google-api-key-am-i-using-in-your-favourite-location-supporting-app
And some other references on the internet about this issue (with AUR): https://stackoverflow.com/questions/53552583/whose-google-api-key-am-i-using-in-your-favourite-location-supporting-app
The expected behavior should be that the API keys are not used when
./xbps-src pkg firefoxor./xbps-src pkg icecatis run not on Void Linux build servers, the--with-google-api-keys=options should be removed. In fact, the key should be secret or only available on the build server...Actual behavior
in the Firefox and IceCat template this line is run unconditionally in the template:
ac_add_options --with-google-api-keyfile="${wrksrc}/google-api-key"Steps to reproduce the behavior
Code examination.
Implication
The implication of this issue would be that any community build is masquerading as official Void Linux build when any of the Google API features are used (Safe Browsing, GeoLocation, etc.)
What kind of access agreement does Void Linux have with Google on use of these APIs? And for the builders (note that I said builders) of IceCat package, there should be a warning/note on this API usage.