[ruby-core:17443] Re: 1.8 release management

Yukihiro Matsumoto wrote:
> From our analysis, we believe all of them just cause segmentation faults at most.  They do not seem to allow
> arbitrary code execution, unlike their report.
That's great news.

> we should have publicly asked the community to test the release candidate (except the vulnerability fixes) first. [...] 
> It might be a good idea to form a larger team for quality assurance.
>   
Agreed.

> I understand you want to fix the release management process not to see
> this kind of trouble again.  But I believe the process isn't broken,
> so we don't need to fix there.  What we need to fix is the process to
> handle security issues.  Since we meet security issues less often than
> usual releases, we sometimes make mistakes to handle them.  We will
> try to find balance between disclosure (to ensure reliability) and
> keeping secret (to ensure security).
I'm not sure what you mean, so forgive my misunderstanding.

I felt the critical problem was the long turnaround time. It's been 11 
days since the public SVN commits were made for crackers to begin 
writing exploits against old versions, but there's still no official 
release that most people can use. It took 8 days before there was any 
official response to the problem with the p230 release. If the old code 
didn't provide arbitrary code execution vectors, we got incredibly lucky.

It'd really help if the ruby-lang and its redmine websites provided a 
clear description of how to get a hold of the dev team to make them 
aware of critical problems, and also have a rotating responsibility so 
that one member is always responsible for checking the ticketing system, 
mailing list, and some special emergencies only email address at least 
once a day.

-igal

PS: Thank you Matz, Urabe Shyouhei, and others for providing us with the 
wonderful Ruby language. It makes me and many others very happy. Sorry 
that we don't get a chance to say that more often. :)