[Development] Proposal: Change Qt's Security Policy to Full Disclosure

[Alexis Menard]

On Fri, Oct 19, 2012 at 11:59 AM, d3fault <d3faultdotxbe at gmail.com> wrote:
> I proposed it, therefore if nobody disagrees, I get consensus and the
> decision goes into effect. I'll quote myself in an earlier post to
> actually give this thread some substance:

Hi,

First you should let more than a day for people to answer.

Secondly I disagree with your statement and using the same link
(Debian) you sent let me quote something else :

"A: Once the security team receives a notification of an incident, one
or more members review it and consider its impact on the stable
release of Debian (i.e. if it's vulnerable or not). If our system is
vulnerable, we work on a fix for the problem. The package maintainer
is contacted as well, if they didn't contact the security team
already. Finally, the fix is tested and new packages are prepared,
which are then compiled on all stable architectures and uploaded
afterwards. After all of that is done, an advisory is published." [1]

Q: How can I reach the security team?

A: Security information can be sent to security at debian.org or
team at security.debian.org, both of which are read by the members of the
security team.

They also have a private mail, only read by the security team.

I'll give you another example. WebKit is the same there is a private
security mailing list.

The fact that *after* the fix is done you do a full public disclosure
is totally fine. But you should keep the exploit private up until the
fix is done.

Now let's say someone found a security flaw in Qt, report the attack
vector and we blindly publish it with the fix not yet in work. What
happen if somebody in the meantime make a proper with bad intention
and spread it over? Millions of products run Qt. Then we don't have
anything to provide to help our user it's too late. When we put the
exploit public, there should already be a patch committed and
announcement made so people can update their Qt before it gets too
late.

[1] http://www.debian.org/security/faq#handling

>
> On Thu, Oct 18, 2012 at 3:40 PM, d3fault <d3faultdotxbe at gmail.com> wrote:
>> tl;dr:
>> Open Project
>> Closed Security
>>
>> The officially endorsed method for reporting security issues for Qt is
>> to send them to security at qt-project.org , which is a private mailing
>> list. I have a problem with that.
>>
>> "Experience has shown that 'security through obscurity' does not work.
>> Public disclosure allows for more rapid and better solutions to
>> security problems" ( http://www.debian.org/security/ ).
>>
>> "Security information moves very fast in cracker circles. On the other
>> hand, our experience is that coding and releasing of proper security
>> fixes typically requires about an hour of work -- very fast fix
>> turnaround is possible. Thus we think that full disclosure helps the
>> people who really care about security" (
>> http://openbsd.org/security.html ).

The report is also on a private part on BSD :

"If you find a new security problem, you can mail it to deraadt at openbsd.org. "

>>
>> If the Qt Project does not intend on taking security issues seriously,
>> then we should remove security related classes from the project
>> (QSslSocket namely). Leaving them in is misleading.
>>
>> d3fault
>
> d3fault
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Software Engineer @
Intel Open Source Technology Center