Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Travis CI Security Advisory: Secured Environment Variables

blog.travis-ci.com

Post reply on HN
Print view View original

31–38 of 38 posts

Re: Travis CI Security Advisory: Secured Environment Variables

#31

Post by nothrabannosir »

tehlike wrote: post #26
nothrabannosir wrote: post #16

Earlier quoted context omitted.

Only if you merge it in. The point is the secure environment variables are not available at all in the fork build. The bash oneliner they show is to help you run scripts which won't crash if they don't have those env vars available, not to "hide them" by running a test script which doesn't use them.

I know many instances where code reviews didnt catch log statement in huge binaries.

Right, but now you're in the "review of a PR didn't catch malicious code" boat. At which point, you've got bigger problems than leaking env vars in your CI.

Not to dismiss it---it's just a different point.

Re: Travis CI Security Advisory: Secured Environment Variables

#34

Post by mattcoles »

arekkas wrote: post #32

Did they bother to notify the repositories affected by this? Could not find anything.

> We have been in close communications with GitHub since we began working on this incident, and have shared impacted tokens with GitHub for their records. GitHub will revoke token access for the affected tokens and will contact token owners to notify them. Both Travis CI and GitHub recommend affected owners revoke their own access tokens and create new tokens immediately.

Seems like both Github and Travis did.

Re: Travis CI Security Advisory: Secured Environment Variables

#35

Post by jacques_chester »

dogecoinbase wrote: post #30
jacques_chester wrote: post #24

Earlier quoted context omitted.

Secrets or credential management is hard, but the first step is to centralise. Many folk use Vault. There's also Knox, KeyWhiz and I forget some others. I've been a secrets-management product team (CredHub) for several months now. We've looked at different ways of shuttling secrets but really, it's going to be specific to the context. For example, one job our software does is to hand credentials to a trusted BOSH dir…

Secrets or credential management is hard, but the first step is to centralise. Ah yes, the "all eggs, one basket" approach to secret management. This is the correct approach, if you are trying to sell a platform -- gets you lock-in, and if you fail to keep secrets secure, you were going to blow up anyways, so the business risk management dictates that you should shoot for the moon and risk your client's data in the h…

That's definitely one way of looking at it.

Another view is that:

1. You can't invest in heavily defending scattered resources.

2. Individual teams are not all experts in secret management.

Pivotal started CredHub (it's now in the Cloud Foundry Incubation process) partly because of client requests and partly because of the problems we and our fellow Cloud Foundry Foundation members have encountered. There are literally thousands of secrets and credentials scattered across dozens of teams, including hundreds of high-risk operational secrets.

We have had multiple unintentional leakages, usually git. It's so easy that we now have tools to watch commits and checkouts for secret-like patterns. The same tools constantly comb our repositories for possible secrets as well.

Development teams should not need to care. Operators should not need to have to hand-manage thousands of secrets. There should be a safe, sane, central, highly assured place or places to keep your secrets.

Re: Travis CI Security Advisory: Secured Environment Variables

#36

Post by lawnchair_larry »

lgas wrote: post #25
eropple wrote: post #21

Earlier quoted context omitted.

How often people log environment variables? Maybe the places I've worked are outliers, but `puts ENV.inspect` or the use of PHP wouldn't pass code review in my prior gigs, nor would they be things I'd write today. My experience is literally the opposite--somebody forgetting a chmod is a lot more common than somebody leaking environment variables like that (leaving it up to somebody to figure out a really smart way to…

I suspect the vast majority of software development organizations do not do code reviews, so you're already in the minority.

Even if they do, they 1) Don't reject PHP wholesale and 2) Don't require that the devops person trying to find a bug go through code review when deploying a debugging tool.

Re: Travis CI Security Advisory: Secured Environment Variables

#38

Post by ReverseCold »

tehlike wrote: post #13
andrewvc wrote: post #4

While I love travis for what it is, this is a foreseeable result here. At the very least they need to add a failsafe that checks all outgoing logs for any secure tokens and replaces them with ' *' or something. If you sign up to play a game of whack-a-mole you will lose eventually.

What if the token was encrypted or altered in a way simple find replace wouldnt work?

Even just encoding it differently (base64, bin, hex, etc) would work against that.
Post reply on HN