Recently some builds on the private repos of the organisation I work for started to fail.
The problem seems to be related to a wrong SSH key being loaded by the travis build.
While before the following message was printed:
Installing SSH key from: repository settings
Now the following one is:
Installing SSH key from: default repository key
And this prevents any of the builds from passing.
Is anyone experiencing something similar? Any chance this may be related to the changes described in Security Bulletin ?
Both our builds have the same config but some of them ignore the repo key and switch back to the default repo key. This started last friday, was there a recent change to the travis config api? Seems like a bug. Why is my ssh key being ignored when its on the settings tab of a specific build?
As a workaround, I have tried adding the encrypted key to .travis.yml, but the build is not able detect the environment variables. It happens only for the pull requests.
That lines up with when ours started doing the exact same thing. Same thing from build logs as well. Even though a key is defined in repo settings, its using the “default repository key” instead. Confirmed via debug build and comparing.
cycling your secrets is something that all users should do on a regular basis. If you are unsure how to do this please contact Support.
We cycled our keys as recommended by the security bulletin but that does not work either. It seems like ssh key variables are plain broken at the moment.
(paid travis-ci.com user) We have a Github private repo in our Org that includes a submodule from a public repo, also from our Org. PR and deployment builds are failing, either at the submodule init or at the hosted Dev/Stage environment for develop-build or master-build. This has halted the code deployment schedule for a major CMS version upgrade of a large website. Also has wasted many hours of dev and devops time to diagnose. We have replaced deployment keys but that has not solved the problem. If Travis can’t solve the problem this week, we will have to find and implement a new CI solution in order to meet deployment schedule.
A temporary workaround we found is to, instead of creating a PR from a fork, pushing the branch to the upstream and then creating the PR from within the same repo (the original).
This seems to allow the proper injection of the key.
FYI. I just got a reply back from support. Here is the contents:
Thank you for contacting Travis-CI Support. I am sorry to hear that you are experiencing issues with Travis-CI. We introduced an enhancement earlier this week that removed the ability to use the base repository SSH key in pull requests from forked repositories. If you want to make a pull request from the fork to the base repository you will need to add the base repository SSH key to the fork before creating a pull request and running builds.
Once again, I am sorry for the inconvenience this may have caused. Please let me know if you have any questions!
But Github deploy keys can only be added to one repo. We tried adding the same key to forked repos but then Github does not let you reuse the key. Then, we tried creating a new key but travis only lets you have one ssh key.
Finally, we try the machine user approach. That did not work either.
How was this rolled out without testing it? The irony of CI.
On our side this is very strange because it seems to be affecting only certain repos which worked flawlessly up to last week. I have gone back to support for further advice.
For Github users: we have implemented a different approach that is now working.
We have a Github Org, with an account that is only used to manage the Org (a “machine user”). We have given the Travis SSH key.pub to that user (Settings: SSH/GPG keys), and removed the key.pub from the Deploy Key on the repository. As long as the key holder user is in a Github Org Team that has permissions on the repo, the key will be found by Travis as the repository key and all users in the team can have successful PR builds from their forked repo to the base/upstream repo.
