Opscode Upgrade to Embedded Ruby


#1

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?

Regards,
Tommy


#2

On Jun 27, 2013, at 6:32 PM, Tommy Fotak Tommy.Fotak@utas.edu.au 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 :slight_smile: (the astute reader will note that this is because there is never any validation)

–Noah


#3

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 <Tommy.Fotak@utas.edu.au (mailto:Tommy.Fotak@utas.edu.au)> 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 :slight_smile: (the astute reader will note that this is because there is never any validation)

–Noah


#4

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 <Tommy.Fotak@utas.edu.au
mailto:Tommy.Fotak@utas.edu.au> 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 :slight_smile: (the astute
reader will note that this is because there is never any validation)

–Noah


#5

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 Tommy.Fotak@utas.edu.auwrote:

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 <Tommy.Fotak@utas.edu.au
mailto:Tommy.Fotak@utas.edu.au> 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 :slight_smile: (the astute
reader will note that this is because there is never any validation)

–Noah


#6

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 bbytheway@gmail.comwrote:

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 Tommy.Fotak@utas.edu.auwrote:

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 <Tommy.Fotak@utas.edu.au
mailto:Tommy.Fotak@utas.edu.au> 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 :slight_smile: (the astute
reader will note that this is because there is never any validation)

–Noah


#7

There’s a patch in 11.6.x alpha (saw on master) that is required for 2.0.0,
iirc, something to do with rubygem/format.

You can build your own omnibus-chef packages (and screw around with the
project/software definitions, etc) really easily, check out the following
projects:



I’d advise that if you feel the Opscode bundled omnibus installations are
not up-to-date enough, consider modifying the Ruby software [0] definition
in omnibus-software, pointing your omnibus-chef Gemfile at your fork/branch
and kicking off the build – you’ll get omnibus packages out of the other
end… Once you have packages, it’s trivial to either host them in a native
package repository or bare HTTP.

One might even consider creating their own ‘omnibus-software’ repository of
definitions to be bundled into omnibus projects for usage in other projects!

Cheers,

AJ

[0]

On Fri, Jun 28, 2013 at 3:20 PM, Morgan Blackthorne
stormerider@gmail.comwrote:

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 bbytheway@gmail.comwrote:

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 Tommy.Fotak@utas.edu.auwrote:

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 <Tommy.Fotak@utas.edu.au
mailto:Tommy.Fotak@utas.edu.au> 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 :slight_smile: (the astute
reader will note that this is because there is never any validation)

–Noah


#8

Thanks folks, you were all a big help.

Tommy

Aj Christensen wrote:

There’s a patch in 11.6.x alpha (saw on master) that is required for
2.0.0, iirc, something to do with rubygem/format.

You can build your own omnibus-chef packages (and screw around with
the project/software definitions, etc) really easily, check out the
following projects:

https://github.com/opscode/omnibus-chef
https://github.com/opscode/omnibus-software
https://github.com/opscode/omnibus-ruby

I’d advise that if you feel the Opscode bundled omnibus installations
are not up-to-date enough, consider modifying the Ruby software [0]
definition in omnibus-software, pointing your omnibus-chef Gemfile at
your fork/branch and kicking off the build – you’ll get omnibus
packages out of the other end… Once you have packages, it’s trivial
to either host them in a native package repository or bare HTTP.

One might even consider creating their own 'omnibus-software’
repository of definitions to be bundled into omnibus projects for
usage in other projects!

Cheers,

AJ

[0]
https://github.com/opscode/omnibus-software/blob/master/config/software/ruby.rb#L19

On Fri, Jun 28, 2013 at 3:20 PM, Morgan Blackthorne
<stormerider@gmail.com mailto:stormerider@gmail.com> wrote:

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
<bbytheway@gmail.com mailto:bbytheway@gmail.com> 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
<Tommy.Fotak@utas.edu.au mailto:Tommy.Fotak@utas.edu.au> 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
<Tommy.Fotak@utas.edu.au mailto:Tommy.Fotak@utas.edu.au
<mailto:Tommy.Fotak@utas.edu.au
mailto:Tommy.Fotak@utas.edu.au>> 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 :slight_smile: (the
astute
reader will note that this is because there is never any
validation)

–Noah


#9

The SSL fix makes me sad. Those familiar with omnibus packaging, how hard
would it be to create an alternate Omnibus distro with cert pinnning for
Hosted Chef?

On Fri, Jun 28, 2013 at 12:05 AM, Tommy Fotak Tommy.Fotak@utas.edu.auwrote:

Thanks folks, you were all a big help.

Tommy

Aj Christensen wrote:

There’s a patch in 11.6.x alpha (saw on master) that is required for
2.0.0, iirc, something to do with rubygem/format.

You can build your own omnibus-chef packages (and screw around with
the project/software definitions, etc) really easily, check out the
following projects:

https://github.com/opscode/omnibus-chef
https://github.com/opscode/omnibus-software
https://github.com/opscode/omnibus-ruby

I’d advise that if you feel the Opscode bundled omnibus installations
are not up-to-date enough, consider modifying the Ruby software [0]
definition in omnibus-software, pointing your omnibus-chef Gemfile at
your fork/branch and kicking off the build – you’ll get omnibus
packages out of the other end… Once you have packages, it’s trivial
to either host them in a native package repository or bare HTTP.

One might even consider creating their own 'omnibus-software’
repository of definitions to be bundled into omnibus projects for
usage in other projects!

Cheers,

AJ

[0]

https://github.com/opscode/omnibus-software/blob/master/config/software/ruby.rb#L19

On Fri, Jun 28, 2013 at 3:20 PM, Morgan Blackthorne
<stormerider@gmail.com mailto:stormerider@gmail.com> wrote:

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
<bbytheway@gmail.com <mailto:bbytheway@gmail.com>> 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
    <Tommy.Fotak@utas.edu.au <mailto:Tommy.Fotak@utas.edu.au>> 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
        <Tommy.Fotak@utas.edu.au <mailto:Tommy.Fotak@utas.edu.au>
        <mailto:Tommy.Fotak@utas.edu.au

        <mailto:Tommy.Fotak@utas.edu.au>>> 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

#10

Can you be more specific Andrew on what you mean by the "ssl fix? Are you concerned that the windows package still does not enforce ssl by default despite including cacert.pem?

To be clear, the work on ssl for Windows isn’t yet done - the goal is to validate the server for all ssl endpoints.

-Adam
From: Andrew Gross <andrew@yipit.commailto:andrew@yipit.com>
Reply-To: "chef@lists.opscode.commailto:chef@lists.opscode.com" <chef@lists.opscode.commailto:chef@lists.opscode.com>
Date: Friday, June 28, 2013 7:24 AM
To: chef <chef@lists.opscode.commailto:chef@lists.opscode.com>
Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Opscode Upgrade to Embedded Ruby

The SSL fix makes me sad. Those familiar with omnibus packaging, how hard would it be to create an alternate Omnibus distro with cert pinnning for Hosted Chef?

On Fri, Jun 28, 2013 at 12:05 AM, Tommy Fotak <Tommy.Fotak@utas.edu.aumailto:Tommy.Fotak@utas.edu.au> wrote:
Thanks folks, you were all a big help.

Tommy

Aj Christensen wrote:

There’s a patch in 11.6.x alpha (saw on master) that is required for
2.0.0, iirc, something to do with rubygem/format.

You can build your own omnibus-chef packages (and screw around with
the project/software definitions, etc) really easily, check out the
following projects:



I’d advise that if you feel the Opscode bundled omnibus installations
are not up-to-date enough, consider modifying the Ruby software [0]
definition in omnibus-software, pointing your omnibus-chef Gemfile at
your fork/branch and kicking off the build – you’ll get omnibus
packages out of the other end… Once you have packages, it’s trivial
to either host them in a native package repository or bare HTTP.

One might even consider creating their own 'omnibus-software’
repository of definitions to be bundled into omnibus projects for
usage in other projects!

Cheers,

AJ

[0]

On Fri, Jun 28, 2013 at 3:20 PM, Morgan Blackthorne
<stormerider@gmail.commailto:stormerider@gmail.com <mailto:stormerider@gmail.commailto:stormerider@gmail.com>> wrote:

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
<bbytheway@gmail.com<mailto:bbytheway@gmail.com> <mailto:bbytheway@gmail.com<mailto:bbytheway@gmail.com>>> 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
    <Tommy.Fotak@utas.edu.au<mailto:Tommy.Fotak@utas.edu.au> <mailto:Tommy.Fotak@utas.edu.au<mailto:Tommy.Fotak@utas.edu.au>>> 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
        <Tommy.Fotak@utas.edu.au<mailto:Tommy.Fotak@utas.edu.au> <mailto:Tommy.Fotak@utas.edu.au<mailto:Tommy.Fotak@utas.edu.au>>
        <mailto:Tommy.Fotak@utas.edu.au<mailto:Tommy.Fotak@utas.edu.au>

        <mailto:Tommy.Fotak@utas.edu.au<mailto:Tommy.Fotak@utas.edu.au>>>> 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

#11

More concerned about this statement “Chef sets :verify_none by default”, I
presumed it was due to issues in Ruby with SSL. I also assumed it was for
*Nix based distros, no experience with Windows.

On Fri, Jun 28, 2013 at 10:35 AM, Adam Edwards adamed@opscode.com wrote:

Can you be more specific Andrew on what you mean by the "ssl fix? Are
you concerned that the windows package still does not enforce ssl by
default despite including cacert.pem?

To be clear, the work on ssl for Windows isn’t yet done — the goal is to
validate the server for all ssl endpoints.

-Adam
From: Andrew Gross andrew@yipit.com
Reply-To: "chef@lists.opscode.com" chef@lists.opscode.com
Date: Friday, June 28, 2013 7:24 AM
To: chef chef@lists.opscode.com
Subject: [chef] Re: Re: Re: Re: Re: Re: Re: Re: Opscode Upgrade to
Embedded Ruby

The SSL fix makes me sad. Those familiar with omnibus packaging, how
hard would it be to create an alternate Omnibus distro with cert pinnning
for Hosted Chef?

On Fri, Jun 28, 2013 at 12:05 AM, Tommy Fotak Tommy.Fotak@utas.edu.auwrote:

Thanks folks, you were all a big help.

Tommy

Aj Christensen wrote:

There’s a patch in 11.6.x alpha (saw on master) that is required for
2.0.0, iirc, something to do with rubygem/format.

You can build your own omnibus-chef packages (and screw around with
the project/software definitions, etc) really easily, check out the
following projects:

https://github.com/opscode/omnibus-chef
https://github.com/opscode/omnibus-software
https://github.com/opscode/omnibus-ruby

I’d advise that if you feel the Opscode bundled omnibus installations
are not up-to-date enough, consider modifying the Ruby software [0]
definition in omnibus-software, pointing your omnibus-chef Gemfile at
your fork/branch and kicking off the build – you’ll get omnibus
packages out of the other end… Once you have packages, it’s trivial
to either host them in a native package repository or bare HTTP.

One might even consider creating their own 'omnibus-software’
repository of definitions to be bundled into omnibus projects for
usage in other projects!

Cheers,

AJ

[0]

https://github.com/opscode/omnibus-software/blob/master/config/software/ruby.rb#L19

On Fri, Jun 28, 2013 at 3:20 PM, Morgan Blackthorne
<stormerider@gmail.com mailto:stormerider@gmail.com> wrote:

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
 <bbytheway@gmail.com <mailto:bbytheway@gmail.com>> 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
     <Tommy.Fotak@utas.edu.au <mailto:Tommy.Fotak@utas.edu.au>>

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
        <Tommy.Fotak@utas.edu.au <mailto:Tommy.Fotak@utas.edu.au>
         <mailto:Tommy.Fotak@utas.edu.au

        <mailto:Tommy.Fotak@utas.edu.au>>> 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

#12

Yay! This will be great for us! Been pulling my hair out waiting for the Windows boxes…

-Pete

On Jun 27, 2013, at 7:45 PM, Benjamin Bytheway bbytheway@gmail.com 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 Tommy.Fotak@utas.edu.au 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 <Tommy.Fotak@utas.edu.au
mailto:Tommy.Fotak@utas.edu.au> 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 :slight_smile: (the astute
reader will note that this is because there is never any validation)

–Noah