On 10/24/12, Samuel Rødal <samuel.ro...@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.kn...@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 <charleyb...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development