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

[Thiago Macieira]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20121025/8337a122/attachment.sig>