On Mon, Oct 8, 2012 at 12:39 AM, Thiago Macieira <thiago.macie...@intel.com> wrote: > Full disclosure *after* we've analysed the bug and delivered a fix, if > necessary. >
Well I think we should change the policy then. Informing application developers that their software might be (or definitely is) at risk is CRUCIAL in applied security. Sometimes the best option is to shut down operations until a fix is provided. By keeping the sploitz behind the scenes, you're empowering those with access to the information and giving the cold shoulder to the application developer. It's not like CRIME was any big secret though. It's not so much of a matter of disclosing the vulnerability so much as it is about informing developers that their software is at risk. > >Disclosing the details about an exploit before it's fixed is bad > practice. That includes similar fixes delivered by others in other products, > not just Qt. > "Other products" don't concern me, so I don't care if they keep their users in the dark. Secure products (OpenBSD, OpenSSL, etc) do full disclosure security, so should we. > > You trust the people who are there, you trust their credentials. We've got > someone who does security analyses for a living. > "Trust" and "Security" are contradicting terms. Also, my dog does security for a living. Think about it, that sentence means nothing. > > We recognise we dropped the ball. So we're working to improve. > Me: Can I halp? Can we have a place to discuss security? You: Nope dis is top secret yo >improve d3fault p.s. if I need to suck your d!c|< for access to incoming security vulns, this "Open Governance" project isn't really open at all. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development