Travis CI flaw exposed secrets of thousands of open source projects (Ars Technica) [LWN.net]

This Ars Technica article describes a problem with the Travis continuous-integration service:

A security flaw in Travis CI potentially exposed the secrets of thousands of open source projects that rely on the hosted continuous integration service. Travis CI is a software-testing solution used by over 900,000 open source projects and 600,000 users. A vulnerability in the tool made it possible for secure environment variables—signing keys, access credentials, and API tokens of all public open source projects—to be exfiltrated.

Any project storing secrets in this service would be well advised to replace them.

to post comments

Storing secrets in 3rd party services

Posted Sep 16, 2021 15:57 UTC (Thu) by dmoulding (subscriber, #95171) [Link] (11 responses)

Any project storing secrets in any 3rd party service would be well advised to stop doing that.

Yes, the vulnerability disclosure and patching process was handled poorly. But the root of the problem here is that it appears to be *standard* practice in a lot of the "industry" to allow 3rd parties to keep and handle sensitive information, like signing keys and authentication tokens. That's the real scandal here.

Storing secrets in 3rd party services

Posted Sep 16, 2021 17:11 UTC (Thu) by hkario (subscriber, #94864) [Link] (5 responses)

Not every project is big enough to run their own infrastructure with dedicated signing servers.

While very much sub-optimal, I expect any "cloud" provider to have better track record of keeping bad guys and viruses out than a random developer doing the same on their workstation.

Storing secrets in 3rd party services

Posted Sep 16, 2021 19:02 UTC (Thu) by ibukanov (subscriber, #3942) [Link] (3 responses)

To store signing keys in a cloud one at least should use a dedicated server to minimize a chance of leaks across VMs. And those can be found for like 10 euro/month.

Storing secrets in 3rd party services

Posted Sep 24, 2021 11:51 UTC (Fri) by nilsmeyer (guest, #122604) [Link] (2 responses)

Where can one get a dedicated server for 10€/month? Cheapest I found was 28€.

Storing secrets in 3rd party services

Posted Sep 25, 2021 5:00 UTC (Sat) by flussence (guest, #85566) [Link] (1 responses)

IIRC OVH had a few bare metal servers in the 7-20€ range, but not under their main brand name, and the specs are pretty dire (Atom CPUs, and single IPv6 /128s last I checked - IPv4 costs extra). They actually sound ideal for this use case because I can't imagine doing anything else with them.

Storing secrets in 3rd party services

Posted Sep 25, 2021 17:32 UTC (Sat) by johill (subscriber, #25196) [Link]

I guess this is the one you were thinking of: https://www.kimsufi.com/us/en/servers.xml

Storing secrets in 3rd party services

Posted Sep 17, 2021 14:40 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

"Bad guys"? Nah. Viruses? Probably. Keeping things on a local machine means that you need targeted specifically (or at least more specifically than "uses Travis CI") for them to leak. Keeping them in the cloud means you're subject to being a side effect of these larger problems.

In short, there's no perfect answer.

Storing secrets in 3rd party services

Posted Sep 17, 2021 0:13 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (3 responses)

If you want to conduct an integration test, it's fairly likely that said test will need to interact with some other service (e.g. the database, another backend, some piece of middleware, etc.). Since that service can't be world-accessible, you need to issue the test some kind of credential so that it can interact with the external service.

Were people doing the Wrong Thing and giving the test code their real production credentials? Quite possibly, for all I know. But nevertheless, it is necessary for testing platforms to handle "secrets" of a sort. Ideally, those secrets should be narrowly scoped and limited to non-production or staging environments, and ideally the testing platform would not leak them. But, well, here we are.

Storing secrets in 3rd party services

Posted Sep 17, 2021 6:28 UTC (Fri) by cpitrat (subscriber, #116459) [Link]

You can just start the database on the VM on Travis. Having contained tests is much better and exposing your database on the web sounds very risky anyway ...

Storing secrets in 3rd party services

Posted Sep 17, 2021 6:40 UTC (Fri) by dvrabel (guest, #9500) [Link] (1 responses)

CI includes automated deployment, or automated upload of build artifacts to artifact repositories (e.g., PyPi), and not just build and test.

Perhaps before calling people dumb, you (and other commenters) should try and understand the problem space first?

Storing secrets in 3rd party services

Posted Sep 17, 2021 21:50 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

I quite deliberately did not call anybody dumb. It was my perception that this is a form of technical debt, and having technical debt is not "dumb" in any reasonable sense of the word.

Perhaps there are also valid reasons for putting real production credentials into a third-party CI system, and perhaps I overlooked those reasons. But I resent the implication that I was flinging insults, when I was in fact doing the opposite.

Storing secrets in 3rd party services

Posted Sep 19, 2021 8:07 UTC (Sun) by njs (subscriber, #40338) [Link]

Very few open-source projects are in a position to build their own data centers.

Travis CI flaw exposed secrets of thousands of open source projects (ars technica)

Posted Sep 17, 2021 21:14 UTC (Fri) by bluss (guest, #47454) [Link]

While I had stopped using travis-ci, since they shut down for open source (more or less), this was a good reminder to also revoke their access to relevant github projects.