[Development] Newlines in XHR / QNetworkAccessManager headers

[Thiago Macieira]

On segunda-feira, 8 de outubro de 2012 02.36.09, d3fault wrote:
> On Mon, Oct 8, 2012 at 12:39 AM, Thiago Macieira
> 
> <thiago.macieira at intel.com> wrote:
> > Full disclosure *after* we've analysed the bug and delivered a fix, if
> > necessary.
> 
> Well I think we should change the policy then. Informing application
> developers that their software might be (or definitely is) at risk is
> CRUCIAL in applied security. Sometimes the best option is to shut down
> operations until a fix is provided. By keeping the sploitz behind the
> scenes, you're empowering those with access to the information and
> giving the cold shoulder to the application developer.
> 
> It's not like CRIME was any big secret though. It's not so much of a
> matter of disclosing the vulnerability so much as it is about
> informing developers that their software is at risk.

Let me rephrase then what I meant:

the security team needs to receive the information and analyse it. It needs to 
determine whether it's a security issue at all, a known one or a new one. 
Usually, known ones are relayed by others, like cert and CVE, and we are bound 
by their rules on when to disclose anything. If we don't follow the rules, we 
have only one option: not receive the notifications.

I'd much rather receive them.

Once the issue is analysed, we contact our security contacts, which usually 
include the Linux distribution security teams, and inform them of the 
existence of the issue (if they didn't know it yet) and when we'll be 
delivering a patch.

At the appropriate time and in coordination with upstream and downstream, 
we'll apply the fix and release the security releases of Qt. We'll also post 
the information on the fact that a security issue has been found and its 
tracking number.

> >Disclosing the details about an exploit before it's fixed is bad
> >
> > practice. That includes similar fixes delivered by others in other
> > products, not just Qt.
> 
> "Other products" don't concern me, so I don't care if they keep their
> users in the dark. Secure products (OpenBSD, OpenSSL, etc) do full
> disclosure security, so should we.

Well, that's good for you that you have to care only about Qt. But we don't 
have that luxury. We have to care about the others too.

If we release the details about an exploit affecting them, including the 
details about how to exploit the issue, before they are fixed, we're increasing 
the problem for them.

Also, most of the security information we receive is via other "security 
centrals". Like I said above, if we don't follow their rules, we'll stop 
receiving the notification. As a user of Qt, I'm sure you appreciate receiving 
a fix sooner rather than later.

> > You trust the people who are there, you trust their credentials. We've got
> > someone who does security analyses for a living.
> 
> "Trust" and "Security" are contradicting terms.
> Also, my dog does security for a living. Think about it, that sentence
> means nothing.

Well, it's also the principle of the Open Governance. You have to trust and 
respect the people with more experience and they'll make the more important 
decisions.

> > We recognise we dropped the ball. So we're working to improve.
> 
> Me: Can I halp? Can we have a place to discuss security?
> You: Nope dis is top secret yo

You're helping now by raising this and pointing out the issue. We'll post the 
procedures for discussion on Dev and it will be available on the wiki once 
it's approved. You're welcome to participate in discussion of the procedures.

As for joining the security mailing list, you'll have to earn that. You can 
understand we'll not allow anyone unknown, out of the blue to join the list -- 
we'd be giving the public (including exploiters) access to confidential 
releases if we did that. 

And you're losing points with me every time you do something like this:

> p.s. if I need to suck your d!c|< for access to incoming security
> vulns, this "Open Governance" project isn't really open at all.

Grow up and we'll maybe start respecting you.

-- 
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/20121008/8412722a/attachment.sig>