Outdated version of LibYAML in latest buildpack release about ruby-buildpack

[cf-gitbot]

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/130619237

The labels on this github issue will be updated when the story is started.

[sesmith177]

Hello @tyyko,

Thanks for the report. We will update the buildpack to use v0.1.7

[flavorjones]

See related https://www.pivotaltracker.com/story/show/130641297 where we should be watching libyaml for new releases.

[sclevine]

Race condition -- didn't realize you already made a story: https://www.pivotaltracker.com/story/show/130641431

[sesmith177]

We decided to remove libyaml from the buildpack in 6a38bf7.

Instead, we use the system-provided libyaml library which has been patched against that CVE.

We expect to release a new version of the Ruby buildpack shortly.

[jchesterpivotal]

Released in v1.6.25.

[schneems]

I looked at the patch, notice in one of the deleted lines there was some logic to clear out previously installed gems after we had to update the libyaml version. I did some digging, it came from heroku/heroku-buildpack-ruby#224. I'm not quite sure how psych links to libyaml or under what conditions a cache purge is required.

[flavorjones]

@schneems thanks for pointing this out. Everything we're shipping in the buildpack, and any gems that get built during staging, will all be dynamically linked against the rootfs's libyaml. So there shouldn't be any side effects to no longer purging the cache to force a recompile. An update to the underlying shared library should theoretically always be sufficient.

[jchesterpivotal]

I'm a bit vague here. For CF we get a fresh container each time, though the buildpack itself is cached. Gems aren't cached.

But it might be a line Heroku need to retain on any servers where the FS is reused for multiple staging events, because the gems might be cached between staging events.

I'm not sufficiently familiar with Heroku's implementation to say either way.