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

[d3fault]

On 10/24/12, Samuel Rødal <samuel.rodal at digia.com> wrote:
> Lars and Charles both provided good lists of reasons in another part of
> this thread for going with the policy of Responsible Disclosure. Clearly
> you disagree on the weighting of the pros and cons, but it doesn't seem
> like you're able to convince anyone else about the superiority of your
> position. At what point will you accept that?
>

dubtef' you're right, I completely missed Lars' response somehow :-/.

I think I've logically proven a vulnerability exists within the Qt
Security Policy. I think what I'm proposing is reasonable. It
accommodates both responsible and full disclosure. Yes I can be an
arsehole at times (triggered especially when I'm talked down to: "let
us make important decisions for you" ... and basically this whole "you
have to trust us with your security" mentality), but skipping over the
argument completely and focusing only on my bad behavior is even worse
than the bad behavior itself.

I should have pseudonym + nice'd this argument, probably would have it
by now. Now we're at the point where those in charge don't want to
give a whiny child his way. Remember, even a broken clock is right
twice a day ;-).


>
> At what point will you accept that?
>

You're asking me at what point I'll stop caring about security...
...uhmmm....
When will you stop locking your doors at night? When will you stop
scanning binaries for virus' (lol as if that does anything :-P)? etc
etc



So I'm late with this, here's my Charley/Lars rebuttal:


On 10/20/12, Knoll Lars <Lars.Knoll at digia.com> wrote:
> In many cases it's unreasonable to ask people to shut down the services
> because it's simply too expensive. Think about a mobile phone like the N9.
> Do you really expect people to turn their phone off for an unknown amount of
> time because there's an exploit?
>

If they value and practice security, ABSOLUTELY. Most end-users do
neither. Why should I (we) suffer for that?

>
> Do you think end users can even judge the
> criticality of the exploit and what kind of measures they could take to
> avoid it? They can't. Often even we, the main developers behind Qt, can't
> know what kind of measures and end user needs to use to protect himself,
> because we don't know how exactly Qt is being used in the product.
>

Precisely why you should allow the _user_ to decide for himself.

>
> Of course one needs to publish fixes for security issues and do updates and
> disclose the problem. But if the issue is not widely known already, we have
> a chance to already provide a fix when we disclose it. The best way I can
> see is to keep these private (for a limited period of time) and work with
> the experts in the area where the issue is to get it fixed as fast as
> possible.
>

See:
http://lists.qt-project.org/pipermail/development/2012-October/007381.html
("Scenario:")
and
http://lists.qt-project.org/pipermail/development/2012-October/007384.html

>
> Most open source projects use a closed security list for exactly the reasons
> above. Even Debian who you cite as a reference has it, and they are
> coordinating disclosure dates with other vendors. Read
> http://www.debian.org/security/ once again, and don't only cite one sentence
> in there out of context. So we will be in good company here, following a
> process very similar to most other OSS projects, including most Linux
> distributions, WebKit, Apache and many others.
>

I shouldn't have referred to Debian, I see that now. OpenBSD is still
a shining example of a secure* product that uses full disclosure.
Referring to other insecure products is irrelevant. Note: a piece of
software is insecure by default unless measures are taken to make it
secure. Even then, it's something you strive for knowing you cannot
attain it. Like perfection. It's still very much worth striving for,
however.

* = security is a state, security policies are a process. Processes
can be improved.

>
> And to make it clear: The Qt project will do full disclosure of the issues.
> The variant we'll be using is in wikipedia called 'Responsible Disclosure'.
>

No, it's not a variant. They are the two competing public disclosure models.
Full = disclosure at discovery
Responsible = disclosure after fix




On 10/20/12, Charley Bay <charleyb123 at gmail.com> wrote:
>> Your concession is interesting:  "His proposal is alright, with the
> exception of handling incoming vulnerabilities."
>
> That was not previously clear to me in the discussion
>

You, like most, didn't read the thread (incl. links) in its entirety
before responding. That's part of the problem too: debating random
people that just respond out of the blue "I THINK RESPONSIBLE
DISCLOSURE IS BETTER AND SO DO MOST PROJECTS" (See:
http://lists.qt-project.org/pipermail/development/2012-October/007367.html
). No reason provided, just a random opinion repeated time and time
again, which unfortunately still sways consensus :(. I count at least
4 that made that very argument (if you even want to call it that).
Lars Knoll included.


>
>(a1) Interruptions/noise is higher with "public" (v. "closed"):  As
>an administrator/user, announcement of a security issue without a fix
>is likely not-actionable, or the "shut-my-stuff-down" action is a
>costly "over-response".  I must await a second announcement, and the
>first announcement is "noise" to which I cannot respond, but against
>which I am now liable (e.g., you've added to my noise, and to my
>liability, without a benefit).
>

A Benefit: Knowledge of the vulnerability's existence, giving you the
ability to protect yourself by shutting down. You think protecting
your + your users' data is an over response? Fine, but I'm glad we
don't work together. Konrad said something similar to me a while ago:
remind me to never use your software :-P.

If you only want to be notified when there's a fix available
(ignorance = bliss), then subscribe to the main ANNOUNCE list only...
simple. Don't force the rest of us to be in the dark with you.

> ...
(a3) and (a4) are basically the same, and actually make me think
you're a [expert] troll in disguise (at least I don't hide it). But
there's a simple counter to it anyways: more eyes on the code/vuln
means that a fix will be found faster than a small group of
individuals, in addition to possibly finding a bug in a fix that a
small group of individuals might miss. This is your strongest
argument, but it's still very weak. Ignoring noise is easy. Just look
at how well others do in ignoring me.

>
>However, I concede that the issue is whether-or-not my four points are
>pragmatically "compelling" in contrast with your-four-points (i.e.,
>your discrete lists of benefits for "open v. closed").
>

Hey, we agree on something yayyy. Copy -> Paste [for my own arguments]...







ALSO, I want to correct what I said in previously. I do think the
naming is rather important (though still nowhere near as important as
the policy itself). Having public = development@ && private =
security@ will end up being misleading. People will think the
only/official way is through security@ ... which is the private one if
we don't change the names -_-


Definitely not giving up as easily as QML. QML is aesthetics and a
problem I can solve myself. Security policy is much more important and
there's nothing I can do but try to convince those in charge to change
it.

Getting tired of repeating myself, but also getting tired of hearing
the same non-argument,
d3fault