| View previous topic :: View next topic |
| Author |
Message |
axios_n
n00b
Joined: 29 Nov 2021
Posts: 9
|
 Posted: Mon Nov 29, 2021 1:54 am Post subject: About Chromium Google Api keys build |
 |
|
I'm new user,i find chromium browser's google api key apply in ebuild file. I think we should add a USE var to enable or disable google api keys,by this way, user can be config the google api key in the /etc/portage/patches/.
like this code:
| Code: |
if use google_api_keys;then
local google_api_key="AIzaSyDEAOvatFo0eTgsV_ZlEzx0ObmepsMzfAc"
myconf_gn+=" google_api_key=\"${google_api_key}\""
fi
|
The google_api_key USE var is default enable,when people change the google api keys, them can disable the google_api_keys USE, and add a patch in /etc/portage/patches to enable them own google api keys.
Thank you.I'm new user, I DON'T KNOWN HOW TO CREATE A PULL REQUEST!!! |
|
| Back to top |
|
 |
Mistwolf
Apprentice
Joined: 07 Mar 2007
Posts: 189
Location: Edmonton, AB
|
| Posted: Mon Nov 29, 2021 2:04 am Post subject: |
|
|
Or, you know, specify your own keys at runtime, as per Chromium docs.
| Quote: | Providing Keys at Runtime
If you prefer, you can build a Chromium binary (or use a pre-built Chromium binary) without API keys baked in, and instead provide them at runtime. To do so, set the environment variables GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET to your "API key", "Client ID" and "Client secret" values respectively.
On Chromium OS to specify the keys as environment variables append them to the end of /etc/chrome_dev.conf:
GOOGLE_API_KEY=your_api_key
GOOGLE_DEFAULT_CLIENT_ID=your_client_id
GOOGLE_DEFAULT_CLIENT_SECRET=your_client_secret |
|
|
| Back to top |
|
|
axios_n
n00b
Joined: 29 Nov 2021
Posts: 9
|
| Posted: Mon Nov 29, 2021 2:16 am Post subject: |
|
|
| Mistwolf wrote: | Or, you know, specify your own keys at runtime, as per Chromium docs.
| Quote: | Providing Keys at Runtime
If you prefer, you can build a Chromium binary (or use a pre-built Chromium binary) without API keys baked in, and instead provide them at runtime. To do so, set the environment variables GOOGLE_API_KEY, GOOGLE_DEFAULT_CLIENT_ID and GOOGLE_DEFAULT_CLIENT_SECRET to your "API key", "Client ID" and "Client secret" values respectively.
On Chromium OS to specify the keys as environment variables append them to the end of /etc/chrome_dev.conf:
GOOGLE_API_KEY=your_api_keychromium-96.0.4664.45
GOOGLE_DEFAULT_CLIENT_ID=your_client_id
GOOGLE_DEFAULT_CLIENT_SECRET=your_client_secret |
|
It's ok, on chromium os or chrome os,but we are gentoo, the best way is build in. |
|
| Back to top |
|
|
axios_n
n00b
Joined: 29 Nov 2021
Posts: 9
|
| Posted: Mon Nov 29, 2021 8:14 am Post subject: |
|
|
I have some code to share: (to solve the build in google api keys,maybe we should add a way allow user change the ebuild file on build system,not as this scripts.)
| Code: |
local patch="/etc/portage/autopatch/${CATEGORY}/${PN}/${PF}.patch"
if [[ -f ${patch} ]]; then
case "${EBUILD_PHASE}" in
setup)
ebegin "Applying user patch"
if /usr/bin/patch --dry-run --quiet --no-backup-if-mismatch -d /var/db/repos/ -p1 < ${patch} > /dev/null; then
einfo "Applying ${patch}"
/usr/bin/patch --quiet --no-backup-if-mismatch -d /var/db/repos/ -p1 < ${patch}; eend $?
fi
;;
postinst)
ebegin "Cleaning user patch"
if /usr/bin/patch --dry-run --quiet --no-backup-if-mismatch -R -d /var/db/repos/ -p1 < ${patch} > /dev/null; then
einfo "Cleaning ${patch}"
/usr/bin/patch --quiet --no-backup-if-mismatch -R -d /var/db/repos/ -p1 < ${patch}; eend $?
fi
;;
esac
fi
|
this scripts add in /etc/portage/bashrc to enable runtime change ebuild file, lt's useful to enable some feature. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Mon Nov 29, 2021 4:43 pm Post subject: |
|
|
I see that the Chromium ebuild passes the normally undefined variable EXTRA_GN after the variable in which the api key is set. Is it not sufficient to assign your own api key there? Untested example: | Code: | | EXTRA_GN=" google_api_key=\"ABC123MyKey\"" emerge --ask --verbose chromium |
If that works, memorizing the custom local key via package.env should work too. |
|
| Back to top |
|
|
axios_n
n00b
Joined: 29 Nov 2021
Posts: 9
|
| Posted: Tue Nov 30, 2021 5:04 am Post subject: |
|
|
Thanks, but can not use.l test it.The api key be covered by ebuild gn args.So,i think the best way is add a USE var to disable or enable ebuild google api key.
This message was mistakenly posted on Gentoo Forums Feedback, so merged with this thread -- fedeliallalinea |
|
| Back to top |
|
|
axios_n
n00b
Joined: 29 Nov 2021
Posts: 9
|
| Posted: Tue Nov 30, 2021 5:10 am Post subject: |
|
|
| Hu wrote: | I see that the Chromium ebuild passes the normally undefined variable EXTRA_GN after the variable in which the api key is set. Is it not sufficient to assign your own api key there? Untested example: | Code: | | EXTRA_GN=" google_api_key=\"ABC123MyKey\"" emerge --ask --verbose chromium |
If that works, memorizing the custom local key via package.env should work too. |
Thanks, I learn some things.I test the way,CAN NOT TO USE, the ebuild build scripts covered the api_key. Add a USE var disable the gn args,can be use this. |
|
| Back to top |
|
|
Hu
Moderator
Joined: 06 Mar 2007
Posts: 21602
|
| Posted: Tue Nov 30, 2021 4:41 pm Post subject: |
|
|
| The method I proposed would append the new key after the old one, so I would expect both keys to be passed. Are you saying that the called Chromium build script only respects the first assignment of google_api_key it sees on the command line, and ignores later ones? Most tools use last-match-wins so that this works. |
|
| Back to top |
|
|
axios_n
n00b
Joined: 29 Nov 2021
Posts: 9
|
| Posted: Wed Dec 01, 2021 12:47 am Post subject: |
|
|
| Hu wrote: | | The method I proposed would append the new key after the old one, so I would expect both keys to be passed. Are you saying that the called Chromium build script only respects the first assignment of google_api_key it sees on the command line, and ignores later ones? Most tools use last-match-wins so that this works. |
Maybe |
|
| Back to top |
|
|
|
Desktop Environments
