On quinta-feira, 25 de outubro de 2012 19.42.12, d3fault wrote: > >What's more important in this is that the > >level of competence and resources in the exploit community varies a lot. I > >can agree that exploiters with vast resources may learn the security > >issues before the full disclosure happens, but I definitely do not agree > >that all exploiters will. > > The amount of resources required to learn of a vulnerability's > existence is lowered significantly once the vulnerability is privately > disclosed to the "trusted circles", for the reason described above and > in many of my previous emails.
Ah, so your claim is that responsible disclosure creates, at the same time, a target group to be hacked and a shortage of information for those affected by the issue. That is, if attackers know that a certain group of people is often aware of possible exploits, they will try to hack that group to gain access to the exploit details. Makes sense. > surely don't trust your ability to keep the information secure. The > chance that the information will leak out is ridiculously high. Most > of the time you don't even know when it happens. Here your logic seems to be: if we create a private group that has security information, this group WILL be hacked, therefore it's pointless to keep the information private anyway. I dispute that. Besides, this argument does not counter mine. I am asserting that the number of attackers who get access to the exploits before they become public is much, much smaller than the number of attackers who would be aware of the information if we disclosed immediately. I don't think you can counter that argument. So this is not about disputing it. It's about deciding which of two evils is the lesser one. This becomes a subjective decision and you know already where the highest deciders in the Qt Project stand. > >There's a waterfall where we lose people upon > > > >the disclosure: > > - most people will not be paying attention > > Those who pay attention should not suffer because of that. True. > > - of those that are paying attention, we lose a great part because the > > > > details are too technical and they are not able to comprehend them, > > not even to determine whether they are affected by the issue > > If you can't determine that, you're probably already so insecure on so > many other levels that the new vulnerability doesn't change anything. > Security is not for the weak of heart. Here you're being completely illogical. I'm talking about disclosing details like "possible buffer overflow in <filename> <line number>". That is, the input discussion of "is there a security problem in the first place?" Most people on this mailing list, talented developers as they are, will not be able to determine whether their code is vulnerable or not and how to patch it. That's because they are not security experts and more than likely the code affected is nowhere near their area of expertise. That being the case, how can I expect the developer of a QML-based application to know how to patch qsslsocket.cpp? No, it's completely unrealistic to assume most people will be able to handle those details. They will be able to handle "here's a patch, please apply it and recompile Qt" or "if you're using this feature, please add this line to your source code". > Those of us who actually practice security should not suffer because > of others' incompetence. Agreed, but irrelevant. We're not talking about others' incompetence. There's no one who is competent in EVERYTHING. Therefore, we need to cope with people who are not competent in everything. If your request then is that we have a mailing list for security matters that is open to everyone, I highly disagree for the reasons I've exposed. We can only accept people there once we're reasonably sure that the person isn't trying to do exactly what you indicated: hack our systems to get access to information that isn't public. > > - of those that did understand the details, we also lose a great part > > because> > > they are unable to come up with a fix or solution for their affected > > systems, short of shutting them down completely > > But that's exactly why you shutdown. It is the safest measure during a > time of uncertainty. A vulnerability has been identified and a fix is > not yet available. Hiding the vulnerability from us does not change > that fact. You don't have to understand the fix (a WIP) to understand > that you're at risk. If this is your world view, here's a suggestion for you, which should immensely increase the security of your systems: Turn them all off. Now. Do not turn them back on. There are definitely lingering security issues we haven't found yet and don't know about. Moreover, we're adding new code every day and some of it could contain issues. So it's reasonable to assume that zero-day hackers may know about them. Since we don't have a fix yet, you should shut down. > The problem, and why we're both right: [snip] Yes, we're both right. Which is why this boils down to a decision on the relative merits of each solution, not just a logical conclusion. And a decision has been made, reached by consensus. I thank you for bringing more arguments to the table and making sure that we're all aware of both sides of the argument. We're all a smarter today because we've learned something. But you have not convinced anyone to change their minds. -- 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 Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
