TL;DR We’re changing the after_script command to run regardless of the test result, previously it was run only on success.

What exactly will change?

Previously, if you specified after_script commands they were run right after the script commands (i.e. your test suite) and only if the script commands were successful (ie. returned 0). This made it virtually the same as the after_success command. Futhermore, there was no way to run commands both on success and failure without specifying them twice in the success and failure stages.

In order to simplify things, we changed after_script to run at the very end, i.e. after the after_success and after_failure stages. after_script will be run no matter what was returned from the previous commands. We will also export a TRAVIS_TEST_RESULT env variable, which contain the test result returned from running the tests in script.

When will the change be deployed?

We plan to deploy this change early next week.

How to fix my .travis.yml?

If commands that you execute in the after_script stage do care about the result of your tests and are not required to be run before after_success command, you probably don’t need to change anything and your tests should run just fine.

If you rely on the fact that a failure in the after_script phase, fails the entire test, you should move, you should move such commands to the script phase.

For example, the following:

script:
  - rake
after_script:
  - build_something_important

should be changed to:

script:
  - rake
  - build_something_important

If you don’t want for those commands to fail the test then move them to the after_success phase.

What happened?

On November 27 we deployed a change to travis-ci.org that exposed private repository keys (used for encrypting sensitive data in .travis.yml files) via an undocumented and unannounced API endpoint. Travis CI for private repositories was not affected by this issue.

This endpoint has been requested for 18 repositories before we were notified about the issue on December 2nd. From examining the access logs these requests looked like legit requests, but we still decided to come forward with this issue as anyone could’ve accessed those endpoints.

How did we fix this?

We have immediately disabled the endpoint and inspected the relevant access logs in order to estimate possible damage.

We have taken the following steps

1. Regenerated keys for affected repos and notified maintainers
2. Add a ‘regenerate key’ button into the web interface
3. Announce the issue by way of this blog post

We have since regenerated the keys on the affected repositories, contacted repository owners and added a way for people to reset their keys manually.

How could this happen?

Our API code generates JSON payloads using service classes that in turn use plain Ruby JSON generator classes, i.e. we do not rely on ActiveRecord’s to_json method normally. Now this particular endpoint was missing a single method call that made it so that ActiveRecord’s to_json magic kicked in and the default logic generated the JSON payload including all attributes on this model. Thus, the private key was included in the payload.

How will we prevent such incidents in the future?

We have a number of changes lined up that will make sure we can not run into something like this this easily again and we will implement them as soon as possible. Some but not all of them include: encryption of this data in the database, removing the ActiveRecord related logic that magically converts models into JSON, adding extra safety nets on the API in order to make sure that generated JSON payloads never contain keys named private_key, password or similar.

How to re-generate your repository key?

Although the vast majority of repositories were not affected, we rolled out a new feature that allows you to regenerate the keys for a repository. If you’re worried about security of your data you can reset your keys. In order to do that, log in to https://travis-ci.org, go to your repository, click on the cog icon on the right and choose “Regenerate Key” option from the menu.

We’re very sorry about this issue. We’re very concerned with the security of our users’ sensitive data. Even though we have talked to the maintainers of all affected projects and though to the best of our knowledge, no harm was caused, this should never happen again.

If you have any questions or feedback regarding SSL keys or security in general, please email us at support@travis-ci.com.

The Travis team loves two things a lot: coffee and meeting people. We also like to hug the people we meet. So why not combine all three and get to know users and customers better and meet them in person?

Today we’re announcing the Travis Coffee Office Hours. You can meet and chat with the Travis team and enjoy some fine coffees, and cake too. Mmmmmmm, cake. The coffee’s on us, of course!

To start things off, we’ll be hanging out at our favorite coffee shops in Berlin and in Wellington on Thursday, December 6. Please stop by if you want to chat about Travis, infrastructure, continuous integration, or anything that’s on your mind.

Café CK, Berlin

In Berlin, you can meet Konstantin, Sven and myself at Café CK on Marienburger Straße. We’ll be hanging out there from 14:00 to 18:00 CET, next Thursday, December 6.

Café CK is a great coffee spot, a must-visit if you’re in Berlin. It’s run by a coffee cupping champion, and they serve a fine selection of coffee roasted in Munich freshly brewed in all kinds of ways.

Flight Coffee Hangar, Wellington

Josh has made his way back to the home island, and is spending some quality time in Wellington, New Zealand. He’s keen to give out free hugs and to have some great coffee along with it.

He even got his pretty face impregnated on a flat white once, for all eternity. Oh wait, no, someone accidentally drank that coffee.

He’s going to be at Flight Coffee Hangar from 14:00 NZDT, also next Thursday, December 6. Come say hi and give the guy a hug!

Hope to see you there! If you can’t make it, not to worry, we plan to make this a recurring occasion.