On Fri, Oct 19, 2012 at 11:59 AM, d3fault <d3faultdot...@gmail.com> wrote: > I proposed it, therefore if nobody disagrees, I get consensus and the > decision goes into effect. I'll quote myself in an earlier post to > actually give this thread some substance:
Hi, First you should let more than a day for people to answer. Secondly I disagree with your statement and using the same link (Debian) you sent let me quote something else : "A: Once the security team receives a notification of an incident, one or more members review it and consider its impact on the stable release of Debian (i.e. if it's vulnerable or not). If our system is vulnerable, we work on a fix for the problem. The package maintainer is contacted as well, if they didn't contact the security team already. Finally, the fix is tested and new packages are prepared, which are then compiled on all stable architectures and uploaded afterwards. After all of that is done, an advisory is published." [1] Q: How can I reach the security team? A: Security information can be sent to secur...@debian.org or t...@security.debian.org, both of which are read by the members of the security team. They also have a private mail, only read by the security team. I'll give you another example. WebKit is the same there is a private security mailing list. The fact that *after* the fix is done you do a full public disclosure is totally fine. But you should keep the exploit private up until the fix is done. Now let's say someone found a security flaw in Qt, report the attack vector and we blindly publish it with the fix not yet in work. What happen if somebody in the meantime make a proper with bad intention and spread it over? Millions of products run Qt. Then we don't have anything to provide to help our user it's too late. When we put the exploit public, there should already be a patch committed and announcement made so people can update their Qt before it gets too late. [1] http://www.debian.org/security/faq#handling > > On Thu, Oct 18, 2012 at 3:40 PM, d3fault <d3faultdot...@gmail.com> wrote: >> tl;dr: >> Open Project >> Closed Security >> >> The officially endorsed method for reporting security issues for Qt is >> to send them to secur...@qt-project.org , which is a private mailing >> list. I have a problem with that. >> >> "Experience has shown that 'security through obscurity' does not work. >> Public disclosure allows for more rapid and better solutions to >> security problems" ( http://www.debian.org/security/ ). >> >> "Security information moves very fast in cracker circles. On the other >> hand, our experience is that coding and releasing of proper security >> fixes typically requires about an hour of work -- very fast fix >> turnaround is possible. Thus we think that full disclosure helps the >> people who really care about security" ( >> http://openbsd.org/security.html ). The report is also on a private part on BSD : "If you find a new security problem, you can mail it to dera...@openbsd.org. " >> >> If the Qt Project does not intend on taking security issues seriously, >> then we should remove security related classes from the project >> (QSslSocket namely). Leaving them in is misleading. >> >> d3fault > > d3fault > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Software Engineer @ Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
