[Development] Proposal: Time to decide what security policy the Qt Project will use (not Trolltech/Nokia/Digia)

d3fault d3faultdotxbe at gmail.com
Fri Oct 26 07:26:21 CEST 2012

>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.

-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

>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

"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.


>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.


More information about the Development mailing list