>this group WILL be hacked Nah. "WILL" is too strong a statement. More like: very very very very likely ;-)
>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. The number isn't very relevant because they are crackers instead of script kiddies. The number of crackers is also a question mark. You simply cannot know how many crackers have gained access to the information. It's better to know that everyone knows than to think* you and your peers are the only ones who know (and to keep the rest of us in the dark). You do not have to fear the script kiddies a single bit if you are armed with the same information as them (because you shut down). * = erroneously >It's about deciding which of two evils is the lesser one. EXACTLY. -A few crackers armed with knowledge you don't have -A ton of script kiddies with knowledge you also have The lesser of two evils is the latter. BECAUSE *copies from above*: You do not have to fear the script kiddies a single bit if you are armed with the same information as them (because you shut down). >you know already where the highest deciders in the Qt Project stand. If I can convince you then you might be able to convince him. Since, you know, he actually respects you and all (brought that upon myself xD). >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?" We should handle it like OpenBSD, erring on the side of caution. If it's definitely a buffer overflow, it should be fixed. The QML people don't have to pay attention to the Security discussions and can continue being oblivious (note: if you are oblivious, you are not secure). "During our ongoing auditing process we find many bugs, and endeavor to fix them even though exploitability is not proven. We fix the bug, and we move on to find other bugs to fix. We have fixed many simple and obvious careless programming errors in code and only months later discovered that the problems were in fact exploitable. (Or, more likely someone on BUGTRAQ would report that other operating systems were vulnerable to a `newly discovered problem', and then it would be discovered that OpenBSD had been fixed in a previous release)" ( http://openbsd.org/security.html ). I would like Qt to be ahead of the game like OpenBSD is. I'd even like to see a minimal/hardened version of Qt where code must first pass extensive auditing. I would happily contribute to that process as it serves me directly. >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". Similarly, they could handle "You are vulnerable. You should shut down to protect yourself" and "Here's a fix, apply it like this and you should be ok to bring yourself back online". >Therefore, we need to cope with people who are not competent in everything. Yes, but we should not simultaneously force those who are competent to suffer. >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. They wouldn't have to hack their way in if you gave them access. You've already shown that it's relatively easy for someone to join the security team. >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. lol. We cannot attain perfection, but we should still strive for it. Yes having your systems online is a risk... and so is going outside. But if you ***KNOW*** there's a man with a gun standing outside your door, you aren't going to go outside. The same is true for knowing of a vulnerability's existence: don't go online until you know it's been dealt with. >Moreover, we're adding new code every day and some of it could >contain issues. See above about a hardened Qt. Moving to Full Disclosure would be a first step towards that. >And a decision has been made, reached by consensus. Leftover corporate policy and a bunch of opinions and other non-arguments. Honestly, this discussion we're having right now has been the only productive one. >But you have not convinced anyone to change their minds. Yet! >We're all a smarter today because we've learned something. Woot, progress. Now I know I shouldn't give up! ...especially since my livelihood depends on it. d3fault _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
