[Development] RFC: Qt Security Policy

d3fault d3faultdotxbe at gmail.com
Wed Oct 10 11:18:28 CEST 2012


Oh right this is where I'm supposed to disagree or object or
something... See:
http://lists.qt-project.org/pipermail/development/2012-October/006892.html

tl;dr: I object on the grounds that behind closed doors security is
not only a waste of time, it also hurts Qt _users_.



Do This:
-CVE/CERT aka private/exclusive notifications go to some email address
that only core security team has access to:
security-private at qt-project.org or something
-security at qt-project.org becomes 'Security' mailing list, public
Read/Write. Only people interested in security read from or post to
this list. Questions, suggestions, etc
-security-announce at qt-project.org/Security-announce mailing list
announces immediately on (a) vuln existence confirmation, (b) vuln fix
(a and b can be grouped together, but a should not wait for b).
Distributors and Qt _users_ alike subscribe to this list, but with
Read-Only access. Core security team has write access
-The regular Qt Announce list does just that: announces major, minor,
and patch (aka security) releases


That way, everybody can both help with and practice security. Security
benefits from more eyes.

With the behind closed doors method, only the special 10 elite full
time security analysis dogs (core security team) get to 'make
important decisions for you' (aka compromise your security) AND those
10 people now have the special ability to sell or exploit that
privileged information before a fix becomes available (a full week of
basically limitless server access, in the case of CRIME). I almost
became a special elite trusted dog analyst myself if only I would have
'kept up the good work' (read: done nothing) for a few more months.
That shows how incredibly easy it is for an adversary to gain access.
They don't even have to be a nice person.

d3fault



More information about the Development mailing list