[chef] Re: Re: Re: Re: Re: Opscode Upgrade to Embedded Ruby

[Morgan Blackthorne < >]

I would also suspect that the 1.9 branch will be maintained and security fixes backported to it for some time to come; jumping to 2.0 probably is not necessary, or desired currently with the given amount of work it will take to implement while 1.9.x is still supported by the Ruby folks.

I mean, if I recall, Chef still technically supports 1.8, that hasn't been officially EOL'd yet.

--

~*~ StormeRider ~*~

"Every world needs its heroes [...] They inspire us to be better than we are. And they protect from the darkness that's just around the corner."

(from Smallville Season 6x1: "Zod")

On why I hate the phrase "that's so lame"... http://bit.ly/Ps3uSS

On Thu, Jun 27, 2013 at 7:45 PM, Benjamin Bytheway < " target="_blank"> > wrote:

I put a pull request in that was merged for 11.6 to bump the omnibus installers to 1.9.3-p429.  Makes a huge difference in speed, especially on windows.

-Ben

On Thu, Jun 27, 2013 at 7:56 PM, Tommy Fotak < " target="_blank"> > wrote:

To be clear it's not so much the vulnerability that concerns me, it's more about keeping the Ruby up to date in general and how that works. For example will the next release be ruby 2.0.0 or still 1.9.3?

Daniel Condomitti wrote:

Are there plans to change that? I would expect that Chef server be one
of the most critical services to ensure you're not being MITM'ed;
especially when using hosted chef.

On Thursday, June 27, 2013 at 6:38 PM, Noah Kantrowitz wrote:

On Jun 27, 2013, at 6:32 PM, Tommy Fotak < " target="_blank">

<mailto: " target="_blank"> >> wrote:

Hi,

What is the policy of Chef releases with regard to Ruby releases?

For example there are ruby 1.9.3-p448 and 2.0.0-p247 releases that
fix an SSL vulnerability, will Opscode make an 11.4.4 release with a
new embedded Ruby?

Are we better off using the Chef gem in our managed Rubies over the
Omnibus?

The relevant bug fix just blocks a potential issue in how Ruby
verifies SSL certificates. Chef sets :verify_none by default, so
there is technically no risk of hitting the bug :-) (the astute
reader will note that this is because there is never any validation)

--Noah