On segunda-feira, 8 de outubro de 2012 02.36.09, d3fault wrote: > On Mon, Oct 8, 2012 at 12:39 AM, Thiago Macieira > > <[email protected]> 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.
Let me rephrase then what I meant: the security team needs to receive the information and analyse it. It needs to determine whether it's a security issue at all, a known one or a new one. Usually, known ones are relayed by others, like cert and CVE, and we are bound by their rules on when to disclose anything. If we don't follow the rules, we have only one option: not receive the notifications. I'd much rather receive them. Once the issue is analysed, we contact our security contacts, which usually include the Linux distribution security teams, and inform them of the existence of the issue (if they didn't know it yet) and when we'll be delivering a patch. At the appropriate time and in coordination with upstream and downstream, we'll apply the fix and release the security releases of Qt. We'll also post the information on the fact that a security issue has been found and its tracking number. > >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. Well, that's good for you that you have to care only about Qt. But we don't have that luxury. We have to care about the others too. If we release the details about an exploit affecting them, including the details about how to exploit the issue, before they are fixed, we're increasing the problem for them. Also, most of the security information we receive is via other "security centrals". Like I said above, if we don't follow their rules, we'll stop receiving the notification. As a user of Qt, I'm sure you appreciate receiving a fix sooner rather than later. > > 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. Well, it's also the principle of the Open Governance. You have to trust and respect the people with more experience and they'll make the more important decisions. > > 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 You're helping now by raising this and pointing out the issue. We'll post the procedures for discussion on Dev and it will be available on the wiki once it's approved. You're welcome to participate in discussion of the procedures. As for joining the security mailing list, you'll have to earn that. You can understand we'll not allow anyone unknown, out of the blue to join the list -- we'd be giving the public (including exploiters) access to confidential releases if we did that. And you're losing points with me every time you do something like this: > 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. Grow up and we'll maybe start respecting you. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
