Travis CI job logs provide important information on executing specific jobs in a build. In addition, build job logs contain supplementary information, such as environment variables names and values, as well as custom debug outputs defined by the users. These debug outputs and unencrypted variables may hold vulnerable secrets (credentials, tokens). As a result, running builds in public repositories could lead to unintended and overlooked exposure of vulnerable information. To minimize risks, Travis CI introduces limits on how long and for whom the job logs will be available. These limits are configurable.
Job Logs
Although Travis CI can handle secrets safely, these may be provided in an unencrypted or unsecured form and exposed in job logs. The job log filters of Travis CI mask most texts that look like secrets, yet some scenarios can bypass existing censoring mechanisms. With the vast amount of daily builds, and the tendency to only review the logs when problems are reported, how can we be sure that secrets have not been accidentally leaked in the logs?
To support users and help prevent malicious actors from finding exposed secrets by scanning legacy Travis CI job logs, especially for public repositories, we are introducing additional functionalities: Enable/Disable access to old build job logs. Limit access to build job logs to a group of repository collaborators with write access.
These new features will provide a certain level of control to the repository owners and admins over the availability of visible Travis CI build job logs. In addition, these new options will help to prevent potential security or confidential details leak from legacy/historical data.
How does it work?
In Travis CI, build job logs follow the availability of repositories. Public repositories have public build job logs available via the Travis CI web user interface and API. If confidential information is leaked in logs, such as users not encrypting their secrets, logs remain public and could be potentially parsed by anyone. Potential consequences could be serious for Travis CI users. Travis CI wants to address this threat by following the policy of giving a control level over the security features to the affected teams since there are multiple workflows and collaboration patterns in the production environment.
At the moment, this means:
Everyone with read access to the repository can see build job logs; it’s a setting available for repository administrators. Build job logs older than 365 days (build job log date decides) are not available; it’s a setting available for repository administrators. Access to the job logs via Travis CI API will now always require API authentication, regardless of whether the repository is public or private.
Now, in the Travis CI Repository Settings, repository administrators and owners have the following options:
Enable access to old build job logs, if this option is OFF, (the default setting), it ensures that job logs older than 365 days are not available to anyone. If set to ON, it will allow access to build job logs older than 365 days with respect to the access setting described below – limit access to build job logs.
If you want to change the 365-day threshold of logs availability, please contact support, pointing out your Version Control System (VCS), respective VCS handle, and repository name.
Limit access to build job logs (users with write/push access only). When this option is OFF (the default setting), access to job logs is much like it is today, which is available for anyone with read access to the repository. That implies the job logs for public repositories may be accessed by everyone. However, when you switch it ON, only users with write/push access to the repository can see the build job logs. Travis CI determines the write/push access based on information received when synchronizing your accounts with your respective VCS. Synchronization happens automatically once a day, and every user can trigger it manually via the ‘Sync account’ button in your account settings.
Additional changes in API
To increase security, the job log is not available without providing API authentication token in the API request, regardless whether the repository is public or private. Job logs requested via API are now provided only via API, no redirections to the storage.
How do I access the job log availability options?
Choose a repository in the Travis CI user interface. Press the More options dropdown menu located in the upper right corner:
Next, select Settings:
Under Security settings, you will find two additional options:
- Enable access to old build job logs
- Limit access to build job logs
All right, is this 365-day period of job logs still available?
Yes, job logs from the last 365 days are still available. Mistakes may happen, and too much may be revealed in debug outputs. Travis CI keeps working on improving job log censoring mechanisms to help you protect your secrets. Still, we strongly recommend: Keep your environment variables hidden in the job logs. Encrypt sensitive data used in your build definition.
Find more documentation for the new job log availability options.
When the Enable access to old build job logs is DISABLED (default), job logs for build jobs, which have a creation date older than 365 days from now, will not be displayed in Travis CI Web UI and will not be available via Travis CI API calls, which do obtain job log contents.
When the toggle is ENABLED, it must work as before the change: all build job logs are available concerning the repository status.
- Public repositories have public job logs (available for everyone).
- Private repositories have private job logs available only to collaborators on the repository.
When the limit access to build job logs is DISABLED (default), the system behaves exactly as in the existing state: users with reading access to the repository have access to build job logs (API may still require an authentication token).
When the toggle is ENABLED, the system will allow access to build job logs only for users recognized as write/push users for the repository.
Travis CI is confident these new features increase security. However, please make sure that people don’t see a need to use secrets in an unsafe way, which will prevent leakage of secrets in the logs.
Happy building!
