Hi all, If I can briefly chip in, you should also add a step where the reporter may review both the fixes and the security announcement before being published. This would add a small safeguard to ensure their concerns were fully addressed before going public. It would also be wise, internally, to ensure a reported issue is fully researched - both Symfony and ZF released XML Injection fixes that only addressed one variation of this attack for a limited number of effected classes and which later needed further fixes in a separate release some months later.
There should be an assumption that a reporter will note something specific and not have performed any extensive code review to find similar, related or underlying issues of equal or greater importance. At the same time, having a public disclosure may allow Bad People to zero on areas that are potentially exploitable so we wouldn't want anything to be overlooked :). Paddy -- Pádraic Brady http://blog.astrumfutura.com http://www.survivethedeepend.com Zend Framework Community Review Team On Fri, Dec 14, 2012 at 7:38 AM, Victor Berchet <vic...@suumit.com> wrote: > Good to see that security concerns are taken seriously. > > Though I hope we won't have to use the new process too soon... nor too late. > > > On Thursday, December 13, 2012 10:04:15 AM UTC+1, Fabien Potencier wrote: >> >> Hi Kousuke, >> >> Thanks a lot for your very detailed email. This is much appreciated. >> Based on your feedback, we are trying to improve the current situation. >> >> Here are the first steps we have already taken: >> >> * I have created a new section on the blog to easily get access to all >> security releases (http://symfony.com/blog/category/security-advisories). >> >> * I have submitted a pull request that improve the page about security >> handling in the docs and improve the steps we must take to resolve >> security issues (you can see the proposed changes here: >> https://github.com/symfony/symfony-docs/pull/2019/files). >> >> * I have created a new URL shortcut that goes directly on the page in >> the docs that talks about security (and list all past security >> advisories): http://symfony.com/security. >> >> * Added the link to the security page in the footer of the mailing-list >> posts. >> >> Fabien >> >> On 12/5/12 9:29 AM, Kousuke Ebihara wrote: >> > Hi, >> > >> > I've read the announcement of symfony 1.4.20 security release. >> > It seems good article because it has necessary and sufficient >> > information. >> > >> > But I don't think good about this has been published at "Sun, 25 Nov >> > 2012 11:07:00 +0100". It was not a business day expect in Line Islands (UTC >> > + 14). >> > Why publishing security release on weekend (oh this word is unclear; >> > means Saturday and Sunday) is not good? Because most of workers may not be >> > able to read that release or not ready for patching. >> > >> > This security release looks like coordinated (means not zero-day >> > attacked / discovered) so there might be opportunity for some adjustments. >> > I >> > hope that security announcement of symfony gets more improvements. >> > >> > I've reviewed past (since symfony 1.0.0) security releases, then noticed >> > some points to be improved: >> > >> > ---------- >> > >> > November 29, 2012: `Security release: Symfony 2.0.19 and 2.1.4 >> > <http://symfony.com/blog/security-release-symfony-2-0-19-and-2-1-4>`_ >> > >> > * No descriptions about the vulnerability is what. So users are >> > not easy to estimate threats and risks. >> > >> > November 25, 2012: `Security release: symfony 1.4.20 released >> > <http://symfony.com/blog/security-release-symfony-1-4-20-released>`_ >> > >> > * As previously noted, this announcement was published on >> > weekend. >> > >> > August 28, 2012: `Security Release: Symfony 2.0.17 released >> > <http://symfony.com/blog/security-release-symfony-2-0-17-released>`_ >> > >> > * (This is very good article due to P�draic Brady's report) >> > >> > May 30, 2012: `Security Release: symfony 1.4.18 released >> > <http://symfony.com/blog/security-release-symfony-1-4-18-released>`_ >> > >> > * No descriptions about the vulnerability is what. (The >> > changelog says this vulnerability is "session fixation attack" but I think >> > this is a wrong) >> > >> > February 24, 2012: `Security Release: Symfony 2.0.11 released >> > <http://symfony.com/blog/security-release-symfony-2-0-11-released>`_ >> > >> > * February 24, 2012 is Friday. I think that avoid to announce >> > security release on Friday is better because some countries may be in >> > Saturday or some people finished one's work of the week. >> > >> > November 16, 2011: `Security Release: Symfony 2.0.6 >> > <http://symfony.com/blog/security-release-symfony-2-0-6>`_ >> > >> > * (This is good article. I worry about this release contains >> > some other changes but this isn't a big problem because a patch to fix >> > vulnerability is provided) >> > >> > March 21, 2011: `symfony 1.3.10 and 1.4.10: security releases >> > <http://symfony.com/blog/symfony-1-3-10-and-1-4-10-security-releases>`_ >> > >> > * March 21, 2011 is Monday. I think that avoid announcing >> > security release on Monday is better because some countries may be Sunday. >> > * According to the original announcement of Doctrine, Doctrine >> > 1 is vulnerable only in case of using PostgreSQL or DB2. But the >> > announcement of symfony doesn't explains that point. >> > >> > June 29, 2010: `Security Release: symfony 1.3.6 and 1.4.6 >> > <http://symfony.com/blog/security-release-symfony-1-3-6-and-1-4-6>`_ >> > >> > * A project doesn't use sfFileCache or doesn't use "Action >> > Cache" is not affected by this vulnerability but this announcement doesn't >> > explain that point. >> > >> > May 31, 2010: `symfony 1.3.5 and 1.4.5 >> > <http://symfony.com/blog/symfony-1-3-5-and-1-4-5>`_ >> > >> > * The title has no information that this announcement is about >> > security release. >> > >> > February 25, 2010: `Security Release: 1.2.12, 1.3.3 and 1.4.3 >> > <http://symfony.com/blog/security-release-1-2-12-1-3-3-and-1-4-3>`_ >> > >> > * This article says "A SQL injection vulnerability ... was >> > reported earlier today ..." but there are no credits of reporter. >> > >> > February 13, 2010: `symfony 1.3.2 and 1.4.2 >> > <http://symfony.com/blog/symfony-1-3-2-and-1-4-2>`_ >> > >> > * The title has no information that this announcement is about >> > security release. >> > >> > April 27, 2009: `symfony 1.2.6: Security fix >> > <http://symfony.com/blog/symfony-1-2-6-security-fix>`_ >> > >> > * (This is good article) >> > >> > October 03, 2008: `symfony 1.1.4 released: Security fix >> > <http://symfony.com/blog/symfony-1-1-4-released-security-fix>`_ >> > >> > * (This is good article. October 03, 2008 is Friday. But it is >> > zero-day publishing vulnerability at >> > http://symfony.com/blog/security-must-be-taken-seriously#comment-12720 so >> > quickly announcement is very good action) >> > >> > May 14, 2008: `symfony 1.0.16 is out >> > <http://symfony.com/blog/symfony-1-0-16-is-out>`_ >> > >> > * The title has no information that this announcement is about >> > security release. >> > * (NOTE: The >> > http://trac.symfony-project.org/wiki/HowToContributeToSymfony#Reportingsecurityissues >> > section is created since this security release) >> > >> > April 01, 2008: `symfony 1.0.13 is out >> > <http://symfony.com/blog/symfony-1-0-13-is-out>`_ >> > >> > * The title has no information that this announcement is about >> > security release. >> > * The body has no information that this announcement is about >> > security release. >> > >> > March 21, 2008: `symfony 1.0.12 is (finally) out ! >> > <http://symfony.com/blog/symfony-1-0-12-is-finally-out>`_ >> > >> > * The title has no information that this announcement is about >> > security release >> > * This article says "As it fixes an important security issue >> > ..." but no explains about the "important security issue" is what. >> > >> > June 25, 2007: `symfony 1.0.5 released (security fix) >> > <http://symfony.com/blog/symfony-1-0-5-released-security-fix>`_ >> > >> > * (June 25, 2007 is Friday, but it is zero-day vulnerability of >> > PHPMailer so quickly announcement is very good action) >> > >> > ---------- >> > >> > I think these announcements of symfony security release are dependent on >> > individual thinks or knowledge; should have some rules and/or standards >> > and/or formats. >> > >> > And I very know writing security release is not an easy task. Detailed >> > information of security release may help attacker, but an obscure one may >> > not be gotten understandings by users. This is a difficult problem. But >> > here's another point -- Symfony has many users all over the world but this >> > program is for web application developer so it may be allowed providing >> > detailed information or exploit code. It should be a consideration too. >> > >> > FYI (1), Ruby on Rails has a list for security announcement: >> > >> > >> > https://groups.google.com/forum/?fromgroups=#!forum/rubyonrails-security >> > >> > Most of announcements have "Versions Affected", "Not affected", "Fixed >> > Versions", "Impact", "Workarounds", "Patches", "Credits" as item. And some >> > announcements contain an example of vulnerability code. I think this is >> > good >> > model case for symfony. >> > >> > FYI (2), IPA (Information-technology Promotion Agency, Japan), is a >> > `Independent Administrative Institution >> > <http://en.wikipedia.org/wiki/Independent_Administrative_Institution>`_ for >> > IT, publishes a useful guideline about announcement of security >> > vulnerability: >> > >> > Vulnerability Disclosure Guideline for Software Developers [PDF] >> > *This is English version so you don't need Japanese skill or friend :)* >> > http://www.ipa.go.jp/security/ciadr/vuln_announce_manual_en.pdf >> > >> > "2. Vulnerability Information: Provide What Users Need " of the >> > guideline says that security announcement should provide to users: >> > >> > * (1) The Product Name and Version >> > * (2) The Date of Publication >> > * (3) Threats >> > * (4) Workarounds >> > * (5) Other Information >> > >> > And "3.1. Items to Be Included in Vulnerability Information" says that >> > the vulnerability information should include: >> > >> > * 3.1.1. Title >> > * A title should have "product name", "vulnerability name", >> > "vulnerability ID", and "indication of 'this is vulnerability information'" >> > * 3.1.2. Overview >> > * An overview of the vulnerability >> > * 3.1.3. Affected Products >> > * A list of affected products >> > * 3.1.4. Description >> > * A description of the vulnerability that has some information >> > like "vulnerability name" and "vulnerability point" >> > * 3.1.5. Threats >> > * 3.1.6. Solution >> > * 3.1.7. Workarounds >> > * 3.1.8. References >> > * 3.1.9. Credit >> > * 3.1.10. Revision History >> > * 3.1.11. Contact Information >> > >> > "3.1.12. Publication Examples" and "4. How to Provide: Navigation to >> > Vulnerability Information on the Web Site" might be interesting so I >> > recommend you to read them. >> > >> > You can see good "navigation to vulnerability information" example from: >> > >> > * http://www.redmine.org/projects/redmine/wiki/Security_Advisories >> > * http://www.mozilla.org/security/announce/ >> > >> > Thanks, >> > Kousuke >> > >> > -- > -- > If you want to report a vulnerability issue on Symfony, please read the > procedure on http://symfony.com/security > > You received this message because you are subscribed to the Google > Groups "symfony developers" group. > To post to this group, send email to symfony-devs@googlegroups.com > To unsubscribe from this group, send email to > symfony-devs+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-devs?hl=en > > -- -- If you want to report a vulnerability issue on Symfony, please read the procedure on http://symfony.com/security You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
