| Summary: | Adding `GITHUB_TOKEN` to `FETCH_EXPORT_VARS` potentially exposes tokens in plaintext | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Jens <jnsk> |
| Component: | bitbake | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | ccasciato, poky.bs.watcher, poky.watcher, randy.macleod |
| Version: | 5.0.14 | ||
| Target Milestone: | 6.1 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Jens
2026-01-16 15:10:50 UTC
Paul put this on our security documentation task list. 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. 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. (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. Bulk move of 6.0 Medium bugs to 6.1. |