16141 2026-01-16 15:10:50 +0000 Adding `GITHUB_TOKEN` to `FETCH_EXPORT_VARS` potentially exposes tokens in plaintext 2026-05-28 13:16:29 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 5.0.14 All Multiple NEW Medium normal 6.1 1 jnsk unassigned ccasciato poky.bs.watcher poky.watcher randy.macleod --- --- Don't know oldest_to_newest 103948 0 jnsk 2026-01-16 15:10:50 +0000 Concerning this commit: https://git.enea.com/cgit/linux/poky.git/commit/bitbake/lib/bb/fetch2/__init__.py?id=aa546ea0c316116d1f6f34f729a9e23f24322e0e It adds `GITHUB_TOKEN` to the `FETCH_EXPORT_VARS`, a list of env vars that get reintroduced to the sanitized environments that bitbake uses while fetching etc. The export vars and their plaintext values then become part of the command line, which may end up in public build logs. Please have another look at this commit; maybe it's expected behavior and fine, but I wanted to alert the maintainers to this potential issue just to be sure. Jens 104020 1 randy.macleod 2026-01-22 15:39:03 +0000 Paul put this on our security documentation task list. 104052 2 paul 2026-01-23 11:03:54 +0000 We should document this in the "Security Manual" section of our documentation. We don't want to remove `GITHUB_TOKEN` from the exported vars as that prevents users from using the token to fetch repositories in the context of GitHub Codespaces / GitHub Actions. If you're publishing build logs, you should always do some filtering/checking to make sure you're not leaking secrets. In the case of GitHub Actions, secret values should already be filtered out of the logs (https://docs.github.com/en/actions/concepts/security/secrets#automatically-redacted-secrets). In GitHub Codespaces or local development environments, you could just run `echo $GITHUB_TOKEN` to print the value, so I don't think we're reducing the protection of the secret value by allowing it to be present in our logs. 104058 3 jnsk 2026-01-23 13:49:12 +0000 FWIW: We're currently using the [~/.git-credentials](https://git-scm.com/docs/git-credential-store#_storage_format) file as a workaround. That is not an ideal solution either, but at least it's not visible outside of the build container. 104060 4 jnsk 2026-01-23 14:01:55 +0000 (In reply to Paul Barker from comment #2) > If you're publishing build logs, you should always do some > filtering/checking to make sure you're not leaking secrets. I strongly disagree with this inversion of responsibility. Especially from a DevOps perspective most people wouldn't even know what secrets to look out for. Build logs are also commonly used to communicate with external partners and support. They are sometimes part of sealed certification packages and should not be tampered with as part of regular operations, IMO. If GH isn't planning on providing a better mechanism soon, I'd suggest to implement the redaction feature as part of bitbake's logging. 105609 5 randy.macleod 2026-05-28 13:16:29 +0000 Bulk move of 6.0 Medium bugs to 6.1.