Re: [Development] Using gcc to build arm version

2012-10-07 Thread song.7.liu 
Another thing: it seems that the libstdc++.so is based on Linux OS, so it can't 
be used for target build...

So for the gcc/g++, is there a standalone library for c++ support ?

Thanks,
Song 

-Original Message-
From: development-bounces+song.7.liu=nokia@qt-project.org 
[mailto:development-bounces+song.7.liu=nokia@qt-project.org] On Behalf Of 
Liu Song.7 (Nokia-MP/Beijing)
Sent: Monday, October 08, 2012 1:38 PM
To: thiago.macie...@intel.com; development@qt-project.org
Subject: Re: [Development] Using gcc to build arm version

readelf -s -W libsupc++.a | grep UND, still shows:

_ZTVN10__cxxabiv120__si_class_type_infoE
_ZTVN10__cxxabiv121__vmi_class_type_infoE
_ZTVN10__cxxabiv117__class_type_infoE

Thanks,
Song

-Original Message-
From: development-bounces+song.7.liu=nokia@qt-project.org 
[mailto:development-bounces+song.7.liu=nokia@qt-project.org] On Behalf Of 
ext Thiago Macieira
Sent: Monday, October 08, 2012 1:24 PM
To: development@qt-project.org
Subject: Re: [Development] Using gcc to build arm version

On segunda-feira, 8 de outubro de 2012 15.18.10, Lincoln Ramsay wrote:
> On 08/10/12 15:09, song.7@nokia.com wrote:
> > collect2 (4.4.1) is used to link.
> 
> If you're linking something that includes C++ you should really use
> g++ as the linker.
> 
> If you're going to invoke ld directly, you need to ensure the 
> appropriate flags are set so it includes the C++ runtime.
> 
> Apparently the library you want is libsupc++.a and it'll be somewhere 
> in your toolchain/sysroot directory.

libsupc++.a is included in libstdc++.so, which comes with most GCC
installations.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center 
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

2012-10-07 Thread d3fault 
On Sun, Oct 7, 2012 at 10:00 PM, Thiago Macieira
 wrote:
> For obvious reasons, the security list is not public and is not open for
> subscription from other people. If you feel you have a reason to be in the
> security mailing list, please mail us there and ask to be subscribed. We're
> looking for people who with the following skills:
>

What are those obvious reasons that trump transparency? Full
disclosure security is the best form of security.

You're talking about an official/internal 'team', whereas I'm talking
about a mailing list. The 'team' would be the only ones with write
access to Security-announce... but everyone should be encouraged to
contribute to Security-discussion. Everything should be done
transparently... else what is Open Governance but a marketing
buzz-word?

Note: discussions between the security team members should take place
entirely on Security-discussion (allowing anybody to join in)... up
until they confirm the vuln and post it on Security-announce.

>
> 1) can provide advice in security-related matters, such as fixes to issues
> 2) can get around Qt's source code (knows where to find things)
> 3) can write code and unit tests, submit to the Qt repository
>

Can you add me then? I mostly just want to read it, but I might be
able to help somewhere.

^^See the problem here? Privileged information. Who knows what major
security holes are sitting in secur...@qt-project.org while the rest
of us sit around with our finger's crossed.

>
> As for the CRIME vulnerability, we had it fixed before the details were made
> public (by way of guessing what the issue was). The problem happened after the
> fix, in getting it published.

Yea some vague IRC discussions were happening between a few
developers, but it took a week+ before an announcement and patch
release was made. A post to Security-announce should have been made
immediately after it was confirmed (some would argue that the
announcement should wait until there's a fix, but I don't).

d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using gcc to build arm version

2012-10-07 Thread song.7.liu 
readelf -s -W libsupc++.a | grep UND, still shows:

_ZTVN10__cxxabiv120__si_class_type_infoE
_ZTVN10__cxxabiv121__vmi_class_type_infoE
_ZTVN10__cxxabiv117__class_type_infoE

Thanks,
Song

-Original Message-
From: development-bounces+song.7.liu=nokia@qt-project.org 
[mailto:development-bounces+song.7.liu=nokia@qt-project.org] On Behalf Of 
ext Thiago Macieira
Sent: Monday, October 08, 2012 1:24 PM
To: development@qt-project.org
Subject: Re: [Development] Using gcc to build arm version

On segunda-feira, 8 de outubro de 2012 15.18.10, Lincoln Ramsay wrote:
> On 08/10/12 15:09, song.7@nokia.com wrote:
> > collect2 (4.4.1) is used to link.
> 
> If you're linking something that includes C++ you should really use 
> g++ as the linker.
> 
> If you're going to invoke ld directly, you need to ensure the 
> appropriate flags are set so it includes the C++ runtime.
> 
> Apparently the library you want is libsupc++.a and it'll be somewhere 
> in your toolchain/sysroot directory.

libsupc++.a is included in libstdc++.so, which comes with most GCC
installations.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using gcc to build arm version

2012-10-07 Thread Thiago Macieira 
On segunda-feira, 8 de outubro de 2012 15.18.10, Lincoln Ramsay wrote:
> On 08/10/12 15:09, song.7@nokia.com wrote:
> > collect2 (4.4.1) is used to link.
> 
> If you're linking something that includes C++ you should really use g++
> as the linker.
> 
> If you're going to invoke ld directly, you need to ensure the
> appropriate flags are set so it includes the C++ runtime.
> 
> Apparently the library you want is libsupc++.a and it'll be somewhere in
> your toolchain/sysroot directory.

libsupc++.a is included in libstdc++.so, which comes with most GCC 
installations.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using gcc to build arm version

2012-10-07 Thread Lincoln Ramsay 

On 08/10/12 15:09, song.7@nokia.com wrote:


collect2 (4.4.1) is used to link.



If you're linking something that includes C++ you should really use g++ 
as the linker.


If you're going to invoke ld directly, you need to ensure the 
appropriate flags are set so it includes the C++ runtime.


Apparently the library you want is libsupc++.a and it'll be somewhere in 
your toolchain/sysroot directory.


Also, mesa itself had a problem with this... perhaps that's what you're 
hitting?

http://lists.debian.org/debian-gcc/2003/02/msg00141.html

--
Link

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using gcc to build arm version

2012-10-07 Thread song.7.liu 
collect2 (4.4.1) is used to link.

Thanks,
Song

From: development-bounces+song.7.liu=nokia@qt-project.org 
[mailto:development-bounces+song.7.liu=nokia@qt-project.org] On Behalf Of 
ext Lincoln Ramsay
Sent: Monday, October 08, 2012 1:00 PM
To: development@qt-project.org
Subject: Re: [Development] Using gcc to build arm version

On 08/10/12 14:57, song.7@nokia.com wrote:
We are building the mesa for Qt, and the gcc is used to build out ARM version.
But the bellow symbols is reported as undefined:

_ZTVN10__cxxabiv120__si_class_type_infoE
_ZTVN10__cxxabiv121__vmi_class_type_infoE
_ZTVN10__cxxabiv117__class_type_infoE

These symbols should be provided by compiler itself, right ?
So is there some compile / link flag required ?

Did you use 'gcc' to link instead of 'g++' ?



--

Link
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

2012-10-07 Thread Thiago Macieira 
On domingo, 7 de outubro de 2012 21.48.22, d3fault wrote:
> > If you find that it's a security issue, contact us at
> > secur...@qt-project.org so we can deal with it.
> 
> Can we get a Security mailing list that uses the email address
> provided above so as to keep the process more transparent? Qt's
> response time to the CRIME vulnerability is/was pathetic (I am
> partially to blame for that -- didn't report it thinking it would be
> fixed upstream in SSL itself).
> 
> Or perhaps two security related lists: Security-discussion (for a
> thread like this) and Security-announce (for confirmed vulns, perhaps
> read-only to the public)?

For obvious reasons, the security list is not public and is not open for 
subscription from other people. If you feel you have a reason to be in the 
security mailing list, please mail us there and ask to be subscribed. We're 
looking for people who with the following skills:

1) can provide advice in security-related matters, such as fixes to issues
2) can get around Qt's source code (knows where to find things)
3) can write code and unit tests, submit to the Qt repository

Even then, we want to keep the team small. The objective of the security 
mailing list is to assess issues being reported and determine whether or not 
an urgent fix is required.

As for the CRIME vulnerability, we had it fixed before the details were made 
public (by way of guessing what the issue was). The problem happened after the 
fix, in getting it published.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Using gcc to build arm version

2012-10-07 Thread Lincoln Ramsay 

On 08/10/12 14:57, song.7@nokia.com wrote:
We are building the mesa for Qt, and the gcc is used to build out ARM 
version.


But the bellow symbols is reported as undefined:

_ZTVN10__cxxabiv120__si_class_type_infoE

_ZTVN10__cxxabiv121__vmi_class_type_infoE

_ZTVN10__cxxabiv117__class_type_infoE

These symbols should be provided by compiler itself, right ?

So is there some compile / link flag required ?



Did you use 'gcc' to link instead of 'g++' ?

--
Link

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Using gcc to build arm version

2012-10-07 Thread song.7.liu 
Hi,

We are building the mesa for Qt, and the gcc is used to build out ARM version.
But the bellow symbols is reported as undefined:

_ZTVN10__cxxabiv120__si_class_type_infoE
_ZTVN10__cxxabiv121__vmi_class_type_infoE
_ZTVN10__cxxabiv117__class_type_infoE

These symbols should be provided by compiler itself, right ?
So is there some compile / link flag required ?

Thanks,
Song
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

2012-10-07 Thread d3fault 
On Sun, Oct 7, 2012 at 4:53 PM, Thiago Macieira
 wrote:
> On domingo, 7 de outubro de 2012 21.23.53, mikko.saa...@nokia.com wrote:
>> xhr.setRequestHeader("Origin","http://www.google.fi\nReferer:http://www.goog
>> le.fi/whatever> >");
>>
>> and this results on the HTTP ===>
>>
>> ORIGIN: http://www.google.fi
>> Referer: http://www.google.fi/whatever
>

Definitely looks like a security risk, thank you for reporting it.

>
> If you find that it's a security issue, contact us at secur...@qt-project.org
> so we can deal with it.
>

Can we get a Security mailing list that uses the email address
provided above so as to keep the process more transparent? Qt's
response time to the CRIME vulnerability is/was pathetic (I am
partially to blame for that -- didn't report it thinking it would be
fixed upstream in SSL itself).

Or perhaps two security related lists: Security-discussion (for a
thread like this) and Security-announce (for confirmed vulns, perhaps
read-only to the public)?

d3fault
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Newlines in XHR / QNetworkAccessManager headers

2012-10-07 Thread Thiago Macieira 
On domingo, 7 de outubro de 2012 21.23.53, mikko.saa...@nokia.com wrote:
> That's one debatable issue, but perhaps there is another more interesting
> case (at least in my opinion). I can also add newlines ("\n" or "\r\n") and
> thus spoof any header, even without that all-caps shouting. This time I
> added the new stuff (still in QML + JS) into the value side of the header
> (also works on the Header part, but then it's all caps [which I suppose
> should not make a difference really]) (interestingly, this attack vector
> did not succeed when I tried supplying malicious input via QML TextInput,
> as the newlines were printed as "\n" [which is good - a header value
> something\nReferer:abc is of no use for an attacker]):
> 
> 
> 
> xhr.setRequestHeader("Origin","http://www.google.fi\nReferer:http://www.goog
> le.fi/whatever >");
> 
> and this results on the HTTP ===>
> 
> ORIGIN: http://www.google.fi
> Referer: http://www.google.fi/whatever

This looks like a bug. First of all, QNAM should do something about it, so 
that the newline is correctly escaped -- if there's such a thing as escaped 
newlines. If there isn't such a thing, we might have to add to the 
documentation that the behaviour is undefined.

As for accessing this from untrusted sources, like JS scripts running on web 
pages, WebKit should do the validation. If it doesn't do that, it's a security 
issue.

> Small bug or something else?

If you find that it's a security issue, contact us at secur...@qt-project.org 
so we can deal with it.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Newlines in XHR / QNetworkAccessManager headers

2012-10-07 Thread Mikko.Saario 
Hello,

I noticed a potential issue when doing some QML/JS XMLHTTPRequest tests 
recently. The "issue" is quite simple as explained below and I would like to 
know what the Qt developer community thinks about it - whether it is a 
"vulnerability" or perhaps just a "feature".

So I was using QML and as far as I can tell it uses the QNetworkAccessManager 
to construct the HTTP requests. As we know, the usual way of adding headers to 
an XHR is:



xhr.setRequestHeader("Header","Value");



I wanted to check out messing with the "forbidden" headers that have a security 
significance (because I know a definite misuse case for it), such as Origin or 
Referer. So you are not supposed to be able to add or modify these in 
JavaScript for obvious reasons.



First of all, I can add an Origin header in JavaScript (well I guess this 
particular header really "came about" with XHR v2 / CORS so perhaps just is not 
"supported" or blacklisted as such yet):



xhr.setRequestHeader("Origin","http://www.google.fi";);

results on the HTTP request ==>

ORIGIN: http://www.google.fi



That's one debatable issue, but perhaps there is another more interesting case 
(at least in my opinion). I can also add newlines ("\n" or "\r\n") and thus 
spoof any header, even without that all-caps shouting. This time I added the 
new stuff (still in QML + JS) into the value side of the header (also works on 
the Header part, but then it's all caps [which I suppose should not make a 
difference really]) (interestingly, this attack vector did not succeed when I 
tried supplying malicious input via QML TextInput, as the newlines were printed 
as "\n" [which is good - a header value something\nReferer:abc is of no use for 
an attacker]):



xhr.setRequestHeader("Origin","http://www.google.fi\nReferer: 
http://www.google.fi/whatever");

and this results on the HTTP ===>

ORIGIN: http://www.google.fi
Referer: http://www.google.fi/whatever



I found Mozilla discussed and apparently fixed a similar, but somewhat wider 
and more damaging issue back in 2005 (Qt case is less severe as the Qt/QNAM 
will apparently only construct one HTTP request, instead of Firefox back then 
sending multiple HTTP requests if you ended the first HTTP request with 
newlines and created a second HTTP request):

https://bugzilla.mozilla.org/show_bug.cgi?id=297078



Here are the (current) specs for XHR I found - listing the headers that should 
not be added programmatically:

http://xhr.spec.whatwg.org/#the-setrequestheader()-method

http://www.w3.org/TR/XMLHttpRequest/#the-setrequestheader-method



I tried this same on Firefox and Chrome (for Win7), they will both fail as 
expected. Another test I made was using the QML browser demo found in the SDK 
that uses the Webkit WebView - this fails as well (i.e. works as intended). In 
that case I loaded a HTML/JS page into the WebView that performed the XHR. And 
as said earlier, the newlines were rendered as string "\n" when I used a QML 
TextInput - which is good. And yes, "same origin" is the target as spoofing 
Host has no effect, but in case of localhost, that could be anything running 
locally.



Small bug or something else?


Mikko Saario

PS My Qt is SDK 1.2.1 with Qt 4.8.1


Axel Oxenstierna - a Swedish nobleman - in 1648, in a letter to his son: "An 
nescis, mi fili, quantilla prudentia mundus regatur?"

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Issues with compiling Qt-Creator on windows

2012-10-07 Thread Majid Khan 
I have tried compiling Qt creator using VS2010 (qt4.8.1) but I am missing
.

It works alright in linux (but thats because inclusion is under
pre-processor directive for Q_OS_WIN.  I have seen this has been issue for
some other people too but haven't seen any fix around it.

Anyone has any idea for a workaround it?

THanks

-- 
Majid Khan
http://www.icplusplus.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QThread usage/guidance

2012-10-07 Thread André Somers 


Op 7 okt. 2012 om 02:20 heeft Sze Howe Koh  het volgende 
geschreven:

> On Sun, Oct 7, 2012 at 4:13 AM, Giuseppe D'Angelo  wrote:
> On 6 October 2012 16:46, Kevin Krammer  wrote:
> >
> > Because it clearly states that QTcpSocket instances returned by that method
> > cannot be used from another thread, making either that note very wrong or
> > recommendation of moveToThread() very dangerous.
> 
> Last time I checked (4.7.something) that piece of documentation was
> actually wrong, and I left wrote a docnote...
> http://qt-project.org/doc/qt-4.8/qtcpserver.html#note-33
> 
> Cheers,
> --
> Giuseppe D'Angelo
> 
> Would you kindly file a bug report, so that your doc note is integrated into 
> the main documentation too?
I think that there are probably a lot of useful bits and pieces that really 
need to go into the main docs in the docnotes. Would it be a good idea to go 
over them and see what gems are there?

André

> 
> 
> Regards,
> Sze-Howe
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Code coverage statistics online

2012-10-07 Thread Sébastien Fricker 
> One possible request: entry marking in the source reports, ie:
> QString QMimeType::filterString() const
> From: 
> http://download.froglogic.com/public/qt5-squishcoco-report/libQtWidgets/source_147.html
> 
> Was the test entered but the if lines not tested?
> 
> Another example: void QMimeTypePrivate::clear()
> 
> It would be more understandable if the entry point was highlighted, instead 
> of the exit point of the block.
> 
> MfG,
> Bill.
This is now available.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development