Re: [Development] Evolving the Qt Project Security Policy

[Richard Moore]

Hi Volker,

A few comments - I wrote the original policy and I'm happy that you're
taking the time to evolve it:



> In addition, we have also been discussing a few aspects in The Qt Company
> where we would like to see the policy evolve, such as:
>
> * the integration of CVE handling into the process of disclosing
> vulnerabilities
>

At the time of writing, getting a CVE was difficult as a result of
bottlenecks within the issuing process (see
https://lwn.net/Articles/679315/ for
background). These issues have now been resolved so I agree they should be
assigned. It may also be worth considering including a CVSS score.


> * the documentation of security-relevant software engineering processes
> that The Qt Company operates today, such as external code audits or
> fuzzing; evolving such processes should be part of the discussion
>

At the time of writing, these activities were not present. I'd be happy to
look at details of them and discuss. If we're going to then there should
also be some consideration made towards threat modelling and the
development of a loosely formalised SDLC.


> * reviewing the way the core security team is operating
>

Indeed.

Cheers

Rich



>
>
> See https://bugreports.qt.io/browse/QTWEBSITE-860 for details. I’d be
> very happy about all contributions.
>
> Note that for the moment, the scope of this continues to be Qt itself,
> rather than surrounding infrastructure and processes.
>
>
> Cheers,
> Volker
>
> [1] https://wiki.qt.io/Qt_Project_Security_Policy
>
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Deprecate the Keccak hashes in QCryptographicHash?

[Richard Moore]

On Tue, 18 Jun 2019 at 17:02, Thiago Macieira 
wrote:

> We have them because we made a mistake when we added SHA3 support. We've
> kept
> them for compatibility, for people who had hashes to compare to and had
> accidentally used Keccak.
>
>
Yes, we should deprecate this.

Rich
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing Albert Astals Cid for Approver

[Richard Moore]

+1

On 21 March 2018 at 12:00, Edward Welbourne  wrote:

> Lars Knoll (21 March 2018 12:49)
> > He isn’t an approver yet? I agree, that we should change that :)
>
> My thought entirely !
>
> +1,
>
> Eddy.
> ___
> 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] Making QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable

[Richard Moore]

On 6 March 2018 at 14:06, Kevin Kofler  wrote:

> Mitch Curtis wrote:
> > https://codereview.qt-project.org/#/c/221758/ makes
> > QObject::dumpObjectTree() and QObject::dumpObjectInfo() invokable so that
> > they can be used from QML.
>
> Would this have any security impact? I'm thinking of issues like ASLR
> bypass
> or other information leakage, if these end up being invokable from
> untrusted
> scripts. Or is all the information contained there already available to
> QML?
>
>
​QML is not safe to run untrusted scripts period.

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

Re: [Development] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11

[Richard Moore]

On 14 February 2018 at 11:36, Konstantin Ritt  wrote:

> Can we have both OpenSSL 1.0.x and 1.1.x supported when configured with
> -openssl-runtime and choose 1.0 or 1.1 with -openssl-linked? Anyhow?
>
>
​No.

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

Re: [Development] Goodbye

[Richard Moore]

​Thanks for all your hard work, and good luck for the future Jake

Rich.
​

On 9 February 2018 at 20:14, Jake Petroules  wrote:

> Steve Jobs once said:
>
> > “I have looked in the mirror every morning and asked myself: "If today
> were the last day of my life, would I want to do what I am about to do
> today?" And whenever the answer has been "No" for too many days in a row, I
> know I need to change something.”
>
>
> After 8 years of Qt, it's time to say goodbye. Both from my employment in
> The Qt Company and my roles in the Qt Project. I'd like to thank those of
> you in the company and in the Qt Project who have supported me over the
> years in various ways. It's been a great adventure. Friday, February 23rd
> will be my last day.
>
> I hereby relinquish my role as Maintainer of Apple build system support
> across all projects under the Qt Project umbrella (nominating Oswald
> Buddenhagen as my replacement), and my role as Maintainer of the Apple
> watchOS platform (nominating Tor Arne Vestbø as my replacement).
>
> Please feel free to contact me at jake.petrou...@petroules.com if you
> have any questions, comments, or otherwise.
>
> I wish you all the best.
>
> Sincerely,
> Jake Petroules
> ___
> 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] Suggestion: switch binary builds to OpenSSL 1.1 in Qt 5.11

[Richard Moore]

On 8 February 2018 at 18:45, Thiago Macieira 
wrote:

> As $SUBJECT says.
>
> Only for 5.11 onward, so shouldn't affect the 5.6 and 5.9 LTS (which don't
> have OpenSSL 1.1 support anyway) or any 5.10.x releases still to come.
>
> As a bonus side-effect, users who hadn't realised they have an old,
> not-up-to-
> date OpenSSL will have to fix the issue.
>
>

​
+1 those who need to use an older version will still be able to build their
own. We really need to start actively pushing people to 1.1.

Cheers

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

Re: [Development] QtCoap: QNAM-like API or not

[Richard Moore]

On 18 January 2018 at 10:07, Konstantin Tokarev  wrote:

>
>
> Heap corruption can be detected with lots of existing tools, e.g. ASAN. It
> also won't be left unnoticed until it's too late, unlike memory leaks which
> may suddenly pop up when amount of data increases.
>
> Debugging out of memory conditions may be much harder.
>

​I suggested adding detection of QNetworkReplies that weren't delete after
a short time period (a few seconds perhaps) as an idea for gammaray to help
with this issue.

Cheers

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

Re: [Development] Qt6 and QCA

[Richard Moore]

Resend from the right address

On 16 October 2017 at 18:38, Richard Moore  wrote:

> I need to polish up my code showing how to add in additional openssl
> features. This can be used to extend it's support without bloating
> qtnetwork or qtbase.
>
> On 13 Oct 2017 8:44 am, "Lars Knoll"  wrote:
>
>> Hi,
>>
>> QCA is being developed outside of qt-project, so we can't easily add it
>> to Qt. Better crypto support would IMO be great to have, but I currently
>> don't think there's any active work ongoing in this area.
>>
>> Cheers,
>> Lars
>>
>> PS: Just as a side note: Adding better crypto support is something we
>> could do without problems in the 5.x series, no need to think about Qt 6
>> because of that :)
>>
>>
>> > On 12 Oct 2017, at 10:58, Tomaz Canabrava  wrote:
>> >
>> > Hello,
>> >
>> > After reading thiago's tougths about the QRandomGenerator I wonder
>> about the status of the Qt Cryptographic Architecture. From what I know
>> it's not a Qt project but it's whidely used for applications that depend on
>> cryptography and ssl, but not activelly maintained.
>> >
>> > There are plans to actually integrate the QCA into Qt as a module - or
>> something similar?
>> >
>> > Best,
>> > Tomaz
>> >
>> >
>> > ___
>> > 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
>>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Repository request: HTTP server

[Richard Moore]

There are also some http servers that I've written. I think requirements
should include:

- Extensible
- Easy to support SSL/TLS
- Support for client certs

I think we talked about some of this at least years network summit...

Cheers

Rich.

On 6 October 2017 at 17:21, Harri Porten  wrote:

>
> On Fri, 6 Oct 2017, Tomaz Canabrava wrote:
>
>   > We have recently been working on a research project looking into
>> the possibilities for creating a lightweight server component that can
>> easily enable Qt
>>   applications to serve over HTTP. We would like to make this work
>> public and therefore request a repository.
>>   >
>>   > This work is intended to continue as a research project, to
>> explore alternatives and reveal areas that need work, so it should be under
>> qt-labs.
>>
>>
>> This is not something similar to what Tufao and Cutelyst are? Perhaps it
>> would be nice to talk to them and see if they can share code.
>>
>> https://cutelyst.org/
>> https://github.com/vinipsmaker/tufao
>>
>
> I'll add a 3rd alternative which are have to started to use for a new
> product:
>
>  http://www.treefrogframework.org
>
> Within open source projects- which are often created for the fun of
> creating something - "work together" proposals don't go anywhere however :)
>
> Harri.
>
>
> ___
> 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] Qt-AES - Looking for comments

[Richard Moore]

On 11 July 2017 at 22:13, Marc Mutz  wrote:

> On 2017-07-08 00:39, Matteo wrote:
>
>> Hi all,
>>
>> I just finished the first preview of my QAESEncryption class and I
>> would like to have some opinions on possible improvements, issues etc.
>>
>> https://github.com/bricke/Qt-AES [1]
>>
>> This is still a work in progress but I feel it's good enough to be
>> shared and I am ready to take the heat!
>>
>
> Don't implement the cipher yourself. Wrap an existing, widely-used and
> audited crypto library instead.
>

​I'm with Marc. I'd also add that anything that uses crypto and directly
references a specific cipher is designed wrong.

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

Re: [Development] syncqt.pl in C++

[Richard Moore]

On 8 March 2017 at 10:37, Kai Koehne  wrote:

> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Richard Moore
> > Sent: Tuesday, March 07, 2017 10:44 PM
> > To: Lars Knoll 
> > Cc: Thiago Macieira ; Qt development mailing
> > list 
> > Subject: Re: [Development] syncqt.pl in C++
> >
> >
> >   You're right. My wording above was misleading, I wasn't present
> > myself. This is what I remembered people telling me afterwards.
> >
> >   Here are the session notes:
> > https://wiki.qt.io/Qt_build_systems_at_QtCon_2016
> > <https://wiki.qt.io/Qt_build_systems_at_QtCon_2016>
> >
> > ​Yep, there's also a video.
>
> I was hosting this session. I don't think it was recorded.
>
>
http://files.kde.org/akademy/2016/A05_Day2_Qt_Build_Systems.mp4

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

Re: [Development] syncqt.pl in C++

[Richard Moore]

>
>
> You're right. My wording above was misleading, I wasn't present myself.
> This is what I remembered people telling me afterwards.
>
> Here are the session notes: https://wiki.qt.io/Qt_
> build_systems_at_QtCon_2016
>
>
​Yep, there's also a video. My recollection is that there was a small vocal
group of people pushing qbs, but that they couldn't demonstrate any actual
advantages it had. They offered a few up, but it turned out that people had
already done that using other tools such as cmake. ​I think the only
conclusion was that qmake is weak and that the maintainers want to stop
maintaining it.

Rich.





> Summary says: "We are thinking about switching build systems. We don't
> know what to do yet, but we can't decide it here."
>
> For me that's inconclusive.
>
> Cheers,
> Lars
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] syncqt.pl in C++

[Richard Moore]

On 7 March 2017 at 21:21, Lars Knoll  wrote:

>
> > On 7 Mar 2017, at 21:54, Thiago Macieira 
> wrote:
> >
> > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore
> escreveu:
> >>> The Qt Company has now very recently made a decision to now go and
> invest
> >>> the man power required to turn qbs into a product we can fully support
> in
> >>> the future. This decision comes from the fact that we see that build
> >>> systems are a very integral part of the developer experience, and it's
> one
> >>> of the areas where we see that there still is a large potential for
> >>> improvement. qbs is promising to bring that improvement to us and our
> >>> users.
> >> ​Pretty depressing since the discussions at the developer summit seemed
> to
> >> conclude the exact opposite.​ I wish those developers were working on
> >> something more useful than a new wheel.
>
> The discussions there were afai remember inconclusive. But the people that
> do the actual work on the build system were mostly positive towards qbs.
>

​You didn't go to that session.​

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

Re: [Development] syncqt.pl in C++

[Richard Moore]

On 7 March 2017 at 19:12, Lars Knoll  wrote:

> Hi,
>
> Thiago's right that there has not been a formal decision in the Qt project
> about the build system to use for Qt 6. So saying qbs will be the build
> system for Qt 6 is getting a bit ahead of things.
>
> But we have had many discussions in the past as well, where the result was
> that the people maintaining the Qt build system would like to see us using
> qbs instead of qmake as the Qt build system in the future. This never lead
> anywhere, as this would have required quite some work to implement the
> functionality required in qbs.
>
> The Qt Company has now very recently made a decision to now go and invest
> the man power required to turn qbs into a product we can fully support in
> the future. This decision comes from the fact that we see that build
> systems are a very integral part of the developer experience, and it's one
> of the areas where we see that there still is a large potential for
> improvement. qbs is promising to bring that improvement to us and our users.
>
>
​Pretty depressing since the discussions at the developer summit seemed to
conclude the exact opposite.​ I wish those developers were working on
something more useful than a new wheel.

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

Re: [Development] Don't use Private *d when your class is immutable

[Richard Moore]

On 3 March 2017 at 11:33, Marc Mutz  wrote:

> On Friday 03 March 2017 10:43:56 Richard Moore wrote:
> [...]
> > QSslCipher should be an integer index into a table. The
> > fact that it isn't is a poor workaround for weak API from​ openssl
>
> Would you mind to expand on that? I don't see any a-priori reason why
> QSslCipher can't be fixed to contain an index (qintptr), from a BC pov.
> What
> in OpenSSL prevents this?
>
>
In order to present info to the user, QSslCipher lets you see things like
the cipher, key length, key exchange method etc. etc. however in SSL these
are all bundled together as a cipher suite - this is just a 16 bit number
(24 bits in SSLv2). What we'd ideally do is just store the number and then
look up the other info as needed. Ideally we'd just query the openssl in
use for the list of available ciphers which we could store as a list/vector
globally. Unfortunately openssl doesn't provide any API for looking up the
info given the id (though i've at least partially got this addressed in
openssl 1.1). At the moment the code has to do some horrendous parsing of a
text representation.
​
Cheers

Rich.​



> > and poor
> > design choices when SSL supported was added to Qt.
>
> Since it was intended as an example for poor design choices, I feel I
> picked
> the correct example :)
>
> Thanks,
> Marc
>
> --
> Marc Mutz  | Senior Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> Tel: +49-30-521325470
> KDAB - The Qt, C++ and OpenGL Experts
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Don't use Private *d when your class is immutable

[Richard Moore]

On 3 March 2017 at 07:30, Marc Mutz  wrote:

> Bad example: QSslCipher. Look at all the messy API that just deals with the
> fact it's pimpled. That class is particularly hideous because it allocates
> memory on every copy!
>
>
​Please avoid using the SSL code as the example since you don't really
understand it. QSslCipher /should/ be an integer index into a table. The
fact that it isn't is a poor workaround for weak API from​ openssl and poor
design choices when SSL supported was added to Qt.

​Cheers

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

Re: [Development] Distributing 3rd party closed source libs

[Richard Moore]

On 30 October 2016 at 09:03, Sean Harmer  wrote:

> What can we do in terms of pre-compiled release builds of Qt? Is it
> feasible for us to distribute the runtime lib required by the plugin from
> the fbx SDK? Or do we need to find some other solution such as build the
> plugin for the release packages but require the user to install the fbx SDK?
>

​​The database plugins need to be compiled separately iirc, but another
option would be to dlopen the autodesk shared library.

Cheers

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

Re: [Development] QDataStream: blackbox or document all versions?

[Richard Moore]

On 26 September 2016 at 10:38, Giuseppe D'Angelo 
wrote:

> Il 25/09/2016 05:58, Thiago Macieira ha scritto:
> anyhow). Plus, the mere existence of that page means that someone is
> relying on the binary format.
>

​IIRC it was added to allow DCOP to be used in non-Qt contexts.

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

[Development] Qt Network Maintainership Changes

[Richard Moore]

Hi All,

As some of you may know, I'm planning to step down as maintainer of Qt
Network. This is because now that the Qt company has people in a position
to work on the network stack full time I think it makes much more sense for
them to be the maintainer - it doesn't mean I'll be moving away from
working on Qt (in fact I hope it will mean I'll have more time to actually
get things done as a result). I'd like to nominate Timur  as my replacement
- he's already spent an inordinate amount of time fixing bugs, to say
nothing of adding support for HTTP/2 so I'm sure things are in good hands.

https://codereview.qt-project.org/#/q/owner:%22Timur+Pocheptsov%22,n,z

On a similar note, I'd like to nominate Jesús Fernández as the maintainer
of the QtNetworkAuth module - he wrote it after all!

https://codereview.qt-project.org/#/q/owner:%22Jesus+Fernandez%22,n,z

I plan to continue working on the network code myself too, this is more an
administrative change than anything else.

Cheers

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

Re: [Development] New repository for QtOAuth

[Richard Moore]

On 12 August 2016 at 11:40, Fredrik de Vibe  wrote:

> Hi all,
>
> We have recently been working on an implementation of OAuth (1+2), and
> this is now approaching a state in which it can be distributed as a tech
> preview. For this we'll need a new public repository.
>
>
​+1​



> The main reason for OAuth to reside in its own module (and not as a part
> of qtnetwork) is that it is specialized, and most qtnetwork users won't
> need it. This avoids increasing the footprint of, and unnecessary
> complexity in, qtnetwork. Another reason is that OAuth, while depending on
> and using networking mechanisms, isn't in itself really a networking
> mechanism.
>

​Yes, I think keeping this as a separate module makes sense. We really just
want qtnetwork to be the core features.

Cheers

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

Re: [Development] Programs crashing left and right in the CI

[Richard Moore]

On 26 July 2016 at 22:33, Henry Skoglund  wrote:

> Hi, most likely I've had too much coffee, but has anyone checked if these
> intermittent crashes are due to outside DDOS/some trying to introduce a
> race condition and injecting new code into Qt's codebase?
>

​The CI machines aren't internet accessible.

Cheers

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

Re: [Development] Source break policy for function overloads

[Richard Moore]

On 13 July 2016 at 19:10, Marc Mutz  wrote:

> Renaming a public inline function of a non-exported class is BC, but SiC
> Type
> (b), so not acceptable.
>

​Good analysis, however isn't the compiler allowed to not inline stuff too
which would mean this example is not b/c either.
​

​Cheers

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

Re: [Development] Retiring libtiff too

[Richard Moore]

On 29 April 2016 at 20:14, Allan Sandfeld Jensen  wrote:

> On Friday 29 April 2016, Thiago Macieira wrote:
> > See https://lists.clearlinux.org/pipermail/dev/2016-April/000290.html
> >
> > This is yet another reason we have to stop bundling third party
> components,
> > especially the image and movie formats.
> >
> > So I recommend dropping the libtiff 3rdparty component and keep the
> plugin
> > for when the system library is found. Our binaries should not include
> > libqtiff.
> Do you have any citations for these issues? TIFF is a pretty important
> format
> being the raw format of many if not most digital cameras. It also isn't a
> web
> format so the vectors of potential attacks are limited
>

​Isn't commonly used on the web, and can't be used on the web are
different. Do we have code that prevents such usage? I'm not aware we even
have an API to limit the set of image format plugins that would get loaded.

Cheers

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

Re: [Development] doc.qt.io certificate issues

[Richard Moore]

On 18 April 2016 at 10:54, Sean Harmer  wrote:

> Hi,
>
> It seems the certificate installed for the above site is incorrect. It
> reports
> itself to be for *.qtcloudapp.com.
>

​Yep, the cert is not valid for this domain. Also note that it expires in
approximately 1 month, so now would be an excellent time to get it updated.

Cheers

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

Re: [Development] Nominating Volker Krause for Approver status

[Richard Moore]

+1

On 30 March 2016 at 09:34, Sean Harmer  wrote:

> Hi All,
>
> I'd like to nominate Volker Krause for approver status. Volker is one of
> the
> main authors of GammaRay, is very active in the Qt Automotive sphere where
> he
> leads up KDAB's contributions, and has touched many parts all over Qt
> (including Qt 3D).
>
> His dashboard is at:
>
> https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z
>
> and reviews at:
>
> https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z
>
> Can I get a +1 please?
>
> Cheers,
>
> Sean
>
> Disclaimer: I work at KDAB with Volker.
> --
> Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK
> Klarälvdalens Datakonsult AB, a KDAB Group company
> Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
> ___
> 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] What qtbase looks like with extensive use of auto

[Richard Moore]

There are certainly quite a few areas of the qtnetwork patch that I think
make the code significantly easier to read. I don't think I'd apply
everything from it, eg. some of the changes from int to auto just make
things less clear in my eyes, but other parts are a massive win. Thanks for
sharing this, it certainly make me think we should be actively using it.

Cheers

Rich.

On 19 March 2016 at 18:02, Stephen Kelly  wrote:

> Hi,
>
> In case you missed it, I wrote an auto-modernizer
>
>  https://steveire.wordpress.com/2016/03/19/aaargh
>
> It is not quite AAA, as it doesn't convert
>
>  QString s;
>
> into
>
>  auto s = QString();
>
> I used it to port qtbase to an extensive use of auto:
>
>  https://github.com/steveire/qtbase/commits/aaa
>
> This isn't something I want to push for Qt to apply, but it's something I
> did and you might find the outcome interesting.
>
> If you think Qt should use auto not-at-all, not-a-lot, or almost-always,
> I'm
> sure you'll find lots of reasons in the commits to support your position.
>
> Thanks,
>
> Steve.
>
>
> ___
> 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] Qt Coding Guidelines

[Richard Moore]

On 16 March 2016 at 21:43, Knoll Lars  wrote:

> Good initiative. I think this is the right idea. Let's put the coding
> guidelines into .qdoc files after having a decision on the ML.
>
> We should actually consider having a section about contributing to Qt in
> our documentation. Coding guidelines would fit nicely into that. But I
> think the .qdoc files should rather live in qtdoc instead of qtbase as most
> of the overview documentation is there.
>

​Personally I think markdown as Kai's used is better since we can link to
that in git and have it rendered sensibly.

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

[Development] Fwd: RFF: nullptr rules

[Richard Moore]

Resending from the right address.

-- Forwarded message --
From: Richard Moore 
Date: 9 December 2015 at 17:22
Subject: Re: [Development] RFF: nullptr rules
To: "development@qt-project.org" 




On 9 December 2015 at 15:14, Marc Mutz  wrote:

> - 0 as a nullptr constant is banned except in tests testing APIs so
>   we don't accidentally require nullptr (ie. all tests should use 0, not
>   nullptr, as far as it makes sense)
>

​This seems pretty arbitrary to me, and would lead to inconsistency with
APIs that ​predated this rule. I can't say I'm in favour.



> - clang-modernize is used to convert all uses of the null pointer constant
> to
>   nullptr, incl. examples, excl. tests and 3rdparty
>

​Won't this just add noise and make forward porting bug fixes harder? I
don't see it gains much.​


> - APIs that require the use of nullptr for disambiguation are discouraged,
>   but may be acceptable to be decided on a case-by-case basis.
>

​Makes sense​


>
> Arguments in favour:
> - it's the C++ way of writing the null pointer constant these days
> - we need to use it in headers, anyway, to allow people to use
> -Wzero-as...,
>   and it makes no sense to have two sets of rules for headers and impl
>

​There's nothing that says we need to allow people to use that warning, and
nothing stopping us disabling it for our headers, so this is a
non-argument.​


> - it can disambiguate code and prevent accidents
>

​I'm not convinced about this for sane APIs.​


> - in some situations, it makes code easier to understand (:
> m_foo(nullptr)).
>
>
I don't see any difference from 0 here to be honest, but perhaps that's
just me.​


> Arguments against:
> - it's uglier than "0", and more to type
>

​Definitely, also:​


- ​It will also make forward-porting​

​bug fixes and merges harder.​

- If the automated change you suggest was done then the history would be (a
little) less useful.

​Cheers

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

Re: [Development] Proposing Markus Goetz

[Richard Moore]

Thanks for the quick resolution!

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

[Development] Proposing Markus Goetz

[Richard Moore]

Not quite sure how Markus has managed not to be an approver.

https://codereview.qt-project.org/#/q/owner:%22Markus+Goetz+(Woboq+GmbH)%22,n,z

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

Re: [Development] Qt 4.8: disabling the CI and closing for anything except security fixes

[Richard Moore]

On 14 August 2015 at 10:45, Knoll Lars  wrote:

> Let’s get that one in as well.
>

​Not really a security fix but we'll also want to get the fix to make
Apple's ancient openssl to work with apple's certificate store in once the
patch is ready.

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

Re: [Development] Use QT_DEPRECATED_SINCE macro for specific enum values

[Richard Moore]

See http://code.woboq.org/qt5/qtbase/src/network/ssl/qssl.h.html#75

Note that qdoc doesn't like it much.

Rich.

On 12 August 2015 at 13:36, Denis Shienkov  wrote:

> Hi All.
>
> Is it possible to use QT_DEPRECATED_SINCE macro for the specific enum
> values? And, is any restrictions related to the different compilers?
>
> enum Numbers {
> One,
> Two,
> #if QT_DEPRECATED_SINCE(5, 2)
> Three,
> #endif
> Four
> };
>
> BR,
> Denis
>
> ___
> 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] Playground request: qtmirserver

[Richard Moore]

On 10 August 2015 at 10:01, Paul Olav Tvete 
wrote:

> I would like to propose a new playground repository for upstreaming the
> QtMir
> project from Canonical:
>

​Will the canonical developers be working directly in this repository? If
so do we need to consider how their changes will be reviewed (ie. do they
need some approvers).

Cheers

Rich.


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

Re: [Development] HEADS-UP: Qt 5.6 feature freeze and branching coming

[Richard Moore]

On 3 August 2015 at 11:55, Heikkinen Jani 
wrote:

> Is there something which prevents us to proceed as planned? Is new CI
> system working well enough etc? Is Qt5.git update working ok in dev?
>
>
> ​CI for Macos is still picking up the wrong openssl (it is using 0.9.8 at
run time). This prevents me from integrating
https://codereview.qt-project.org/#/c/113855/ which was requested for
qtcreator.

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

Re: [Development] Support for custom Diffie-Hellman parameters in QSslSocket

[Richard Moore]

Hi Mikkel,

Please could you upload your change to gerrit so I can review it properly?
I was actually implementing this yesterday, but since you've got it done
I'll abandon my change. If you add me as the reviewer then I'll add the
other relevant people. The change seems mainly okay, but there are a few
minor things need fixing (some incorrect \since statements, missing
autotest etc.).

Cheers

Rich.

On 25 May 2015 at 23:16, Mikkel Krautz  wrote:

> Hi,
>
> I've been working on adding the ability to set custom DH parameters
> for QSslSocket and I want to start discussing an API for the feature,
> rather than jumping directly to a code review.
>
> I have a preliminary patch that adds a sketch of the API I'm envisioning:
> https://gist.github.com/mkrautz/699f3c7fb22f48b7059c
> (It's untested, but it builds...)
>
> Basically, what I'm envisioning is
>
>  - An opaque (for the user) QSslDiffieHellmanParameters class.
>  - It loads DH parameters either as PEM or DER via a constructor that
> takes a QByteArray or a QIODevice (like QSslKey).
>  - After loading, isNull() can be used to check if the DH parameters
> were loaded, and were valid (OpenSSL backend uses DH_check -- not sure
> what should be done on SecureTransport, if anything?).
>  - Internally, the QSslDiffieHellmanParameters object stores a
> DER-encoded version of the parameters. (This makes it easily loadable
> in both OpenSSL and SecureTransport)
>  - A public QSslConfiguration::setDiffieHellmanParameters() to set the
> DH parameters.
>  - A public (but not in the public headers)
> QSslConfiguration::diffieHellmanParameters() for internal use by the
> backends.
>  - QSslDiffieHellmanParametersPrivate will befriend QSslContext (for
> OpenSSL) and an equivalent for SecureTransport to allow the
> implementations to access the DER encoded data of the
> QSslDiffieHellmanParameters.
>
> I did a cursory web search for the ability to set DH parameters for
> WinRT listeners, but I don't think that's possible -- so I haven't
> considered that, for now...
>
> Let me know what you think.
>
> Thanks,
> Mikkel
> ___
> 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] Git clone hangs on Linux using SSH

[Richard Moore]

On 13 March 2015 at 21:08, Denis Shienkov  wrote:

> So, nor SSH, nor HTTS does not work for me. What happens? :(
>

You're using the wrong port.

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 10 March 2015 at 14:22, Jan Kundrát  wrote:

> On Sunday, 22 February 2015 16:27:44 CET, Giuseppe D'Angelo wrote:
> > * RHEL 6 ships 1.0.0, EOL Nov 2020
>
> This is a bit more complex with RHEL because there are many "RHEL 6"s. RHEL
> 6.5 and newer ship with 1.0.1e [1], so they are already covered. The older
> OpenSSL 1.0.0 was present in 6.0 to 6.4. The "Extended User Support" for
> 6.4 ended a week ago [2], so if I understand their support policies
> correctly, any supported RHEL6 is today on a new enough OpenSSL.
>

Excellent, thanks for the clarification.

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 22 February 2015 at 18:02, Thiago Macieira 
wrote:

> > No, there will be no more updates for < 1.0.1 after december. The
> lifespan
> > of 1.0.1 has not yet been set. They seem to be doing the work to make the
> > code more maintainable, then they'll probably have a longer lifespan.
>
> I meant security fixes, unless you also meant those.
>
>
I meant those. This is the end of the road for those versions.

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

[Development] Qtbase 5.5 branch is blocked

[Richard Moore]

The qtbase 5.5 branch has been blocked by the revdep for qtdeclarative all
weekend, but I'm still seeing people staging stuff there. Is anyone
actually looking at fixing the problem, or are people just blindly staging
things? The evidence suggests the latter. :-(

https://codereview.qt-project.org/#/c/106722/
https://codereview.qt-project.org/#/c/106856/
https://codereview.qt-project.org/#/c/106783/

I do have to question if people are actually looking at the CI results.

Thoroughly unimpressed

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 22 February 2015 at 20:08, Sorvig Morten 
wrote:

>
> > On 22 Feb 2015, at 18:50, Jeremy Lainé  wrote:
> >
> > On 02/22/2015 06:42 PM, Richard Moore wrote:
> >>
> >>
> >> On 22 February 2015 at 17:39, Jeremy Lainé 
> wrote:
> >>
> >> Whilst I agree with the goal of dropping support for old / unmaintained
> >> OpenSSL versions, in the case of OS X we probably need to map out the
> >> transition in more detail - especially what policy to follow for the
> >> official binary releases. My main concern is that in Qt 5.5 the
> >> SecureTransport backend is available on OS X, but as far as I know we
> >> are still aiming for OpenSSL-based binaries. This means that a lot of
> >> users will not be exposed to this new backend at all, and then suddenly
> >> in Qt 5.6 the old backend will be completely gone, with no way to build
> >> it even from source.
> >>
> >> I think you're misunderstanding. Openssl will remain supported, just
> not the outdated 0.9.8 branch apple ship. Users will still be able to make
> use of openssl on mac they'll just have install a newer version. Does this
> change your concerns?
> >>
> >
> > I understood what you were saying, I think I just expressed my concerns
> poorly. When I said "now way to build even from source", I meant "no way to
> build support for OpenSSL as shipped by Apple". Anyway, my main concern is
> : how do we encourage OS X users to make use of the new backend, to avoid
> nasty surprises when it because the default backend?
>
> Ideally I'd like to ship both backends in the binary package, with a
> runtime switch to select the active one, and make SecureTransport the
> default. Users can then file bugs and ship their applications using the
> OpenSSL backend if needed.
>
> This requires some changes to the 5.5 branch - both backends are named
> "QSslSocketBackendPrivate".
>

Run-time switching isn't even something we've considered. I doubt it's
feasible in the 5.5 time frame unless someone has quite a chunk of time to
devote to it. It would require changes all over the place including the
configure script. Might be a nice thing to have though.

Cheers

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 22 February 2015 at 17:50, Jeremy Lainé  wrote:

>  On 02/22/2015 06:42 PM, Richard Moore wrote:
>
>
>
> On 22 February 2015 at 17:39, Jeremy Lainé  wrote:
>
>>
>> Whilst I agree with the goal of dropping support for old / unmaintained
>> OpenSSL versions, in the case of OS X we probably need to map out the
>> transition in more detail - especially what policy to follow for the
>> official binary releases. My main concern is that in Qt 5.5 the
>> SecureTransport backend is available on OS X, but as far as I know we
>> are still aiming for OpenSSL-based binaries. This means that a lot of
>> users will not be exposed to this new backend at all, and then suddenly
>> in Qt 5.6 the old backend will be completely gone, with no way to build
>> it even from source.
>>
>
>  I think you're misunderstanding. Openssl will remain supported, just not
> the outdated 0.9.8 branch apple ship. Users will still be able to make use
> of openssl on mac they'll just have install a newer version. Does this
> change your concerns?
>
>
> I understood what you were saying, I think I just expressed my concerns
> poorly. When I said "now way to build even from source", I meant "no way to
> build support for OpenSSL as shipped by Apple". Anyway, my main concern is
> : how do we encourage OS X users to make use of the new backend, to avoid
> nasty surprises when it because the default backend?
>
>
I see. Okay, well one way to encourage them is that apple don't ship
openssl on iOS, so we'll certainly get some coverage that way. I think
another is that we'll have to ask them to. :-) Note that we already don't
really support 0.9.8 so this isn't actually much of a change. I suspect
many users will already have a newer openssl on their system anyway which
can be used.

Hopefully we'll start getting some feedback on how people are finding the
SecureTransport backend during the betas.



> Slightly off-topic but related : does the Qt Company have any privileged
> access to Apple engineers working on Secure Transport? I would like to
> understand what the plans are regarding support for NPN / ALPN.
>

No idea on that one, but I'd imagine they'll want to support http/2 in
safari at some point.

Cheers

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 22 February 2015 at 17:39, Jeremy Lainé  wrote:

> Hi Rich,
>
> On 02/21/2015 06:30 PM, Richard Moore wrote:
> > Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
> > frame:
> >
> > * Complete removal of openssl 0.9.8 support
> >
> > This has been unsupported for a while and was really only retained
> > since it is the only version apple ship on OS X (though they don't
> > actually recommend using it). Qt 5.5 introduces the new
> > SecureTransport backend for SSL so there's now no good reason to
> > continue having all the ifdefs.
>
> Whilst I agree with the goal of dropping support for old / unmaintained
> OpenSSL versions, in the case of OS X we probably need to map out the
> transition in more detail - especially what policy to follow for the
> official binary releases. My main concern is that in Qt 5.5 the
> SecureTransport backend is available on OS X, but as far as I know we
> are still aiming for OpenSSL-based binaries. This means that a lot of
> users will not be exposed to this new backend at all, and then suddenly
> in Qt 5.6 the old backend will be completely gone, with no way to build
> it even from source.
>

I think you're misunderstanding. Openssl will remain supported, just not
the outdated 0.9.8 branch apple ship. Users will still be able to make use
of openssl on mac they'll just have install a newer version. Does this
change your concerns?

Cheers

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 21 February 2015 at 18:38, Thiago Macieira 
wrote:

> > I suspect enterprise distros etc. will continue to support 1.0.0 for a
> > while. I'm not sure of the level of adoption of 1.0.1 at the moment, so I
> > was erring on the side of caution. Any feedback on this is welcome.
>
> And with CII supporting OpenSSL now, I don't think we should have a problem
> with old versions getting updates.
>
>
No, there will be no more updates for < 1.0.1 after december. The lifespan
of 1.0.1 has not yet been set. They seem to be doing the work to make the
code more maintainable, then they'll probably have a longer lifespan.

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 21 February 2015 at 18:38, Konstantin Ritt  wrote:

> 2015-02-21 22:05 GMT+04:00 Richard Moore :
>
>>
>> On 21 February 2015 at 17:34, Konstantin Ritt  wrote:
>>
>>> 2015-02-21 21:30 GMT+04:00 Richard Moore :
>>>
>>>> Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
>>>> frame:
>>>>
>>>> * Complete removal of openssl 0.9.8 support
>>>>
>>>> This has been unsupported for a while and was really only retained
>>>> since it is the only version apple ship on OS X (though they don't actually
>>>> recommend using it). Qt 5.5 introduces the new SecureTransport backend for
>>>> SSL so there's now no good reason to continue having all the ifdefs.
>>>> Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
>>>> the support from the sources, I suspect this will involve some changes to
>>>> how the library is searched for when we use dlopen.
>>>>
>>>
>>> To me, it looks like a subject for 5.5. Why not?
>>>
>>>
>> 5.5 is already feature frozen.
>>
>
> The SecureTransport backend has been already introduced - that's a
> feature, a dep. library version bump is not :)
> Well, IMO.
>
>
This way we have a whole release cycle for people to try the
SecureTransport backend and report any problems, much as I'd love to remove
the 0.9.8 code already (after all I've already said I won't support it
quite some time ago) I think this is a reasonable balance.

Cheers

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 21 February 2015 at 17:54, Giuseppe D'Angelo  wrote:

> On 21 February 2015 at 18:30, Richard Moore  wrote:
> > Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
> the
> > support from the sources, I suspect this will involve some changes to how
> > the library is searched for when we use dlopen.
>
> As well as 1.0.0. Should we make Qt 5.6 require 1.0.1 directly?
>
>
I suspect enterprise distros etc. will continue to support 1.0.0 for a
while. I'm not sure of the level of adoption of 1.0.1 at the moment, so I
was erring on the side of caution. Any feedback on this is welcome.

Cheers

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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 21 February 2015 at 17:34, Konstantin Ritt  wrote:

> 2015-02-21 21:30 GMT+04:00 Richard Moore :
>
>> Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
>> frame:
>>
>> * Complete removal of openssl 0.9.8 support
>>
>> This has been unsupported for a while and was really only retained since
>> it is the only version apple ship on OS X (though they don't actually
>> recommend using it). Qt 5.5 introduces the new SecureTransport backend for
>> SSL so there's now no good reason to continue having all the ifdefs.
>> Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
>> the support from the sources, I suspect this will involve some changes to
>> how the library is searched for when we use dlopen.
>>
>
> To me, it looks like a subject for 5.5. Why not?
>
>
5.5 is already feature frozen.

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

[Development] SSL Plans for Qt 5.6

[Richard Moore]

Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
frame:

* Complete removal of openssl 0.9.8 support

This has been unsupported for a while and was really only retained since it
is the only version apple ship on OS X (though they don't actually
recommend using it). Qt 5.5 introduces the new SecureTransport backend for
SSL so there's now no good reason to continue having all the ifdefs.
Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
the support from the sources, I suspect this will involve some changes to
how the library is searched for when we use dlopen.

* As I've been trying to for ages, I'd like to get the support for OCSP and
OCSP stapling implemented.

* If possible, I'd like to get the rework of the ssl errors API discussed
at last years QtCS implemented.

Cheers

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

[Development] MacosX/iOS SecureTransport SSL Backend Call for Testers

[Richard Moore]

The secure transport backend for Qt's SSL support was merged earlier this
week [1] thanks to some great work by Jeremy Laine and Timur
Pocheptsov. Please could those using Macos X and iOS give it a try and see
how it works for them?

Cheers

Rich.

1. https://codereview.qt-project.org/#/c/101485/
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Feature freeze approaching

[Richard Moore]

The main one I'm aware of the the securetransport SSL backend. I'm hoping
to spent some time looking at it, but more eyes would help.
https://codereview.qt-project.org/#/c/101485/

Cheers

Rich.

On 29 January 2015 at 10:02, Knoll Lars  wrote:

> Hi everybody,
>
> Just a short reminder to you all that the feature freeze and branching of
> Qt 5.5 is approaching. The current plan is to branch 5.5 on the 9th of
> February.
>
> If you have any feature that should really go in and still needs review
> let me know, and I'll try to help getting it reviewed.
>
> Cheers,
> Lars
>
> ___
> 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] Certificate expires soon, new one ordered

[Richard Moore]

Sigh. It looks like some of the tests are using qt-project.org even though
they aren't supposed to:

void
tst_QSslSocket_onDemandCertificates_member::onDemandRootCertLoadingMemberMethods()
{
QString host("qt-project.org");

// not using any root certs -> should not work
QSslSocketPtr socket2 = newSocket();
this->socket = socket2.data();
socket2->setCaCertificates(QList());
socket2->connectToHostEncrypted(host, 443);
QVERIFY(!socket2->waitForEncrypted());

Grr.

Rich.


On 26 January 2015 at 20:54, Richard Moore  wrote:

>
>
> On 26 January 2015 at 19:28, Marc Mutz  wrote:
>
>> I guess that's the reason why no integration succeeds in qtbase atm
>> (always
>> some ssl test error)?
>>
>> If so, it might be a good idea to suspend qtbase integration tasks until
>> it's
>> fixed, unless people like to have it running as a compilation oracle...
>>
>
> The network test server doesn't depend on the qt-project cert.
>
> Rich.
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Certificate expires soon, new one ordered

[Richard Moore]

On 26 January 2015 at 19:28, Marc Mutz  wrote:

> I guess that's the reason why no integration succeeds in qtbase atm (always
> some ssl test error)?
>
> If so, it might be a good idea to suspend qtbase integration tasks until
> it's
> fixed, unless people like to have it running as a compilation oracle...
>

The network test server doesn't depend on the qt-project cert.

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

Re: [Development] QSsl: finer-grained protocol selection

[Richard Moore]

On 28 December 2014 at 13:26, Thiago Macieira 
wrote:

> On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
> > At the moment there are still a lot of SSL accelerators out there with
> > these problems. We can probably stop worrying in around a year once all
> the
> > browsers have got around to disabling SSL3 and thereby forcing things to
> be
> > fixed. Currently we will already fail to connect to these servers, but
> the
> > API we provide allows users to implement workarounds in their own code.
> If
> > we change the meaning of the TLSv1 constant in this way then it would no
> > longer be possible for them to do this.
>
> Ah, I see.
>
> Then we just add to the list:
>
> TlsV1_0OrLater,
> TlsV1_1OrLater,
> TlsV1_2OrLater
>
> When TLS 1.3 comes into existence, we add:
>
> TlsV1_3,
> TlsV1_3OrLater
>
>
I think this is probably the way to go. It's certainly the easiest to
implement with the openssl backend.


> Alternatively, we can add a
>
> /// if major == 0, sets to "Secure Protocols"
> void setMinimumTlsVersion(int major, int minor);
> int sessionTlsMajorVersion() const;
> int sessionTlsMinorVersion() const;
>
> And deprecate setProtocol.
>

I'd also be okay with this,

Cheers

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

Re: [Development] QSsl: finer-grained protocol selection

[Richard Moore]

On 27 December 2014 at 12:48, Thiago Macieira 
wrote:

> On Saturday 27 December 2014 10:52:41 Richard Moore wrote:
> > Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
> > then if you're connecting to old servers the TLS extensions will lead the
> > connection to hang. Perhaps what we want is a minimum and maximum version
> > (though this doesn't map very well to the underlying openssl API).
>
> Why? Let's assume we're this is 2014 today and that any non-broken server
> has
> been upgraded to support TLSv1, since SSLv3 is now known to be not as
> secure.
> Is the connection hanging still a problem? And even if it is, isn't that an
> OpenSSL problem, not ours?
>
>
At the moment there are still a lot of SSL accelerators out there with
these problems. We can probably stop worrying in around a year once all the
browsers have got around to disabling SSL3 and thereby forcing things to be
fixed. Currently we will already fail to connect to these servers, but the
API we provide allows users to implement workarounds in their own code. If
we change the meaning of the TLSv1 constant in this way then it would no
longer be possible for them to do this.

Cheers

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

Re: [Development] QSsl: finer-grained protocol selection

[Richard Moore]

On 27 December 2014 at 11:44, Mikkel Krautz  wrote:

> On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore  wrote:
> > On 26 December 2014 at 21:12, Thiago Macieira  >
> > wrote:
> >
> > Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
> > then if you're connecting to old servers the TLS extensions will lead the
> > connection to hang.
>
> Hi Rich,
>
> Thanks for the clarification.
>
> I assume this means that QSsl::SecureProtocols (the default) is also broken
> when connecting to buggy servers? Or does Qt's HTTP logic do TLS-specific
> retries if something fails?
>
>
It's not broken, but yes it could fail to connect. If an app needs to
support such broken servers it can then specify the older version using the
TLSv1_0 constant. That's why changing the meaning of the constant would be
a problem.



> How about a QSsl::SslOption for triggering the behavior Thiago suggested?
> (Making it opt-in would also avoid a change in behavior for existing
> programs
> using TlsV1_0 an friends).
>
>
I actually think it probably makes more sense to either allow you to
specifically set the versions, or to have an API for the min and max
versions you want. If I was coding this from a clean slate I suspect I'd
make the protocol version a Q_FLAGS so you can just turn on and off the
ones you want. It might be possible to do this actually and make the
current API still work.


> Our use case in Mumble is a little special, since our main use of TLS isn't
> HTTP-related, so hopefully the amount of buggy TLS implementations is
> limited. I believe we "only" have implementations using OpenSSL,
> PolarSSL and Go's crypto/tls in the wild, and I haven't seen problems with
> Thiago's approach yet (but I'll admit that I haven't extensively tested it
> yet).
>
>
The buggy implementations are mainly SSL accelerators so I suspect you
won't have a problem.


> > Perhaps what we want is a minimum and maximum version
> > (though this doesn't map very well to the underlying openssl API).
>
> Well at least it seems to fit OpenSSL's API better than it fits the API
> that the
> WinRT backend is using. I'm guessing that's a problem?
>
If an explicit QSsl::SslOption is required to trigger the behavior, the docs
> for the option could at least explain that it might not work with all
> backends.
>
>
Yeah, there are a number of differences in behaviour in the winrt (and
securetransport) backends. These are mainly due to missing features in
their APIs and I suspect will remain unavoidable. It shouldn't prevent us
providing the API we want, though obviously where possible I'd like to keep
things compatible.

Cheers

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

Re: [Development] QSsl: finer-grained protocol selection

[Richard Moore]

On 26 December 2014 at 21:12, Thiago Macieira 
wrote:

>
> I don't think we need fine-grained detection, but we do need something
> better
> than what we have right now.
>
> My suggestion is to set a level. For example, if you set to TlsV10, then
> you
> get TLS v1.0 and anything newer, existing today or not, and disable
> anything
> older. The client will negotiate the highest version at connection time.
> The
> only reason to disable newer versions is when the server is buggy, but the
> application should not have to care about that. That's OpenSSL's job.
>
>
Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
then if you're connecting to old servers the TLS extensions will lead the
connection to hang. Perhaps what we want is a minimum and maximum version
(though this doesn't map very well to the underlying openssl API).

Cheers

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

Re: [Development] Qt 5.4.0 header diff: QtX11Extras.diff

[Richard Moore]

This one is fine.

Rich.


On 18 November 2014 14:38, Frederik Gladhorn <
frederik.gladh...@theqtcompany.com> wrote:

>
> ___
> 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] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.

[Richard Moore]

On 10 September 2014 21:15, Thiago Macieira 
wrote:

> On Tuesday 09 September 2014 18:24:58 Валерий Котов wrote:
> > I realize that we had this discussion before. But I have to ask. =)
> > Does not it make sense to add method and type in Operations enum for
> > options in case we need some special treatment for "OPTIONS" verb?
>
> Only if we have a method for it and we're not adding one. If it's just
> sendCustomVerb, then we don't need an enum entry.
>
> By the way, do you know of who would need OPTIONS *? What's the use-case,
> who
> would use it and how do they do it today?
>
>
Given the previous discussions referenced from the working groups for
xmlhttprequest I think it's pretty clear that we can forget about OPTIONS
*. Just using a custom verb and implementing it in the xmlhttprequest
implementation of qml seems like the way to go.

Cheers

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

Re: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.

[Richard Moore]

On 4 September 2014 10:29, Allan Sandfeld Jensen  wrote:

> On Thursday 04 September 2014, Richard Moore wrote:
> > On 3 September 2014 20:25, Thiago Macieira 
> >
> > wrote:
> > > > > How is it represented in HTML5?
> > > > > Just do it the same way.
> > > >
> > > > I'm a little unsure that I understood. Could you please clarify what
> > > > did you mean by "represented in HTML5"?
> > >
> > > XMLHttpRequests have existed in JavaScript and HTML5 for years. How do
> > > they do
> > > this?
> >
> > I actually looked at the specs (both level 1 and level 2) the other day
> and
> > OPTIONS * isn't mentioned at all.
> >
> At least in WebKit, it is an allowed method for open(), eg.
> xhr.open('OPTIONS',..)
>
>
Yeah, the spec mentions OPTIONS, just not the special case of sending an
OPTIONS * request.

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

Re: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.

[Richard Moore]

On 3 September 2014 20:25, Thiago Macieira 
wrote:

> > > How is it represented in HTML5?
> > > Just do it the same way.
> >
> > I'm a little unsure that I understood. Could you please clarify what did
> > you mean by "represented in HTML5"?
>
> XMLHttpRequests have existed in JavaScript and HTML5 for years. How do
> they do
> this?
>
>
I actually looked at the specs (both level 1 and level 2) the other day and
OPTIONS * isn't mentioned at all.

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

Re: [Development] Updating the licence policy for Qt Project

[Richard Moore]

On 27 August 2014 14:55, Oswald Buddenhagen 
wrote:

> On Fri, Aug 22, 2014 at 07:21:38AM +, Knoll Lars wrote:of course lgpl2
> still makes sense for add-ons hosted outside qt-project,
> and ones where the author explicitly doesn't want digia to make money
> from selling this module (though in this case i wouldn't host on
> qt-project to start with).
>
>
I think it's a bad idea to start mixing qt-project decisions with digia
decisions. If a 3rd party wants to release an addon as part of Qt and it's
LGPLv2 then I think that's just fine. Digia making money on things should
be independent of qt-project decisions. I also think digia should be able
to release stuff under whatever license they want to - and those parts that
are opensource should also live in qt-project.

Cheers

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

[Development] Fwd: Nominating Milian Wolff as approver

[Richard Moore]

-- Forwarded message --
From: Richard Moore 
Date: 15 July 2014 22:55
Subject: Re: [Development] Nominating Milian Wolff as approver
To: Gladhorn Frederik 


He isn't already? +1

Rich.



On 15 July 2014 21:08, Gladhorn Frederik 
wrote:

> Hi all,
>
> it's my pleasure to nominate Milian Wolff as approver. He's a great guy,
> works for KDAB and has done interesting work on profiling, improves
> KDevelop amongst other things and has been active with all things web it
> seems.
> He's started and is maintaining the qtwebchannel repository which is
> getting more and more attention lately. He's great to work with and based
> in Berlin. I think he makes a great addition to the list of Qt approvers.
>
> His submissions:
>
> https://codereview.qt-project.org/#/q/owner:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z
>
> Reviews:
>
> https://codereview.qt-project.org/#/q/reviewer:%22Milian+Wolff+%253Cmilian.wolff%2540kdab.com%253E%22,n,z
>
> Cheers,
> Frederik
>
> ___
> 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] libressl

[Richard Moore]

The 2.0.1 release of libressl has addressed the problem and it now builds.

Rich.



On 13 July 2014 11:14, Richard Moore  wrote:

> Just to save anyone else trying, I had a quick go of building Qt against
> libressl and it isn't currently capable of building Qt. The problems are
> likely to be relatively easily fixed (in libressl), but right now it
> doesn't work.
>
> Rich.
>
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] libressl

[Richard Moore]

Just to save anyone else trying, I had a quick go of building Qt against
libressl and it isn't currently capable of building Qt. The problems are
likely to be relatively easily fixed (in libressl), but right now it
doesn't work.

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

Re: [Development] Guidelines for reporting bugs in Qt

[Richard Moore]

Overall this is very good, but there are a couple of things that could be
improved:

- Asking people for a unit test in the bug tracker when we're not allowed
to include this in Qt without submission via gerrit seems likely to cause
conflict. I'd suggest either removing this section or explaining a
mechanism that would allow the test to be used.

- Please make clear that security issues should be reported to
secur...@qt-project.org

Cheers

Rich.



On 3 July 2014 15:31, Friedemann Kleint  wrote:

> Hi,
>
> as a result of internal discussions at Digia, I have updated
> http://qt-project.org/wiki/ReportingBugsInQt a bit. The motivation
> behind this is that we want the bug reports as good as possible since
> many roles in the Qt project deal with them (developers, code reviewers,
> release managers, people trying to check for regressions, ...) and thus
> it is important that bug reports are easy to understand and to reproduce.
>
> I would like to have more opinions on the guidelines at
> http://qt-project.org/wiki/ReportingBugsInQt . Is there anything missing
> that would make fixing bugs easier in the modules you maintain?
>
> Once we have the guidelines in a good shape, they will be shown
> prominently on the JIRA-landing page.
>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint
> Digia, Qt
>
> ___
> 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] Request for sandbox area: QQSM

[Richard Moore]

On 23 June 2014 18:21, Stottlemyer, Brett (B.S.)  wrote:

> As for Replicant, yes we will need have a playground established for that.
>
> According to
> http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt, I need
> approval from a Qt Maintainer before I can submit a new Gerrit project.  Do
> I have said approval?
>

Sure, everyone seemed to think replicant was interesting and most questions
were matters of detail, so I'll approve that.

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

[Development] QtNetwork QtCS Session

[Richard Moore]

The notes from the network session are online at
http://qt-project.org/groups/qt-contributors-summit-2014/wiki/QtCS14QtNetwork
for those who couldn't attend (or those who did but can't remember what we
said). Thanks to Danimo for minuting this.

Cheers

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

Re: [Development] Adding support for version number comparisons

[Richard Moore]

On 2 June 2014 13:12, Keith Gardner  wrote:

> On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann 
> wrote:
>
>>
>> I suggest a name that is more centric towards the _function_ of the class,
>> comparison of different software versions.
>>
>
> QVersionInformation was also proposed as a name in the code review.  I
> don't have a problem with changing the name other than it is really long
> for a simple class.
>
>
How about QVersionComparator?

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

Re: [Development] Update on iOS / SSL implementation

[Richard Moore]

What Jeremy has done here is fantastic. My estimate when I was previously
asked how hard it was to write a new backend to the SSL support was
approximately a man month given a developer who already knew the subject
area. I'm extremely please that someone has been willing to make this
investment in time, effort and given the nature of SSL/TLS sheer
frustration. Thank you.

Not having a Mac, I can't test this, but I'll have a long look over the
code and see what I can do to help get this integrated.

Rich.





On 29 May 2014 18:26, Jeremy Lainé  wrote:

> A while back I posted some proof of concept code to show what an
> implementation of QSslSocket might look like using Secure Transport.  I
> have continued along these lines, and wanted to keep you updated.
>
>
> 1. GENERAL
>
> Apple's Secure Transport API is available both on OS X and iOS. As I do
> not have a iDevice, I have been developing on OS X exclusively, but
> making sure the methods I use are available on iOS (iOS only has a
> subset of OS X's capabilities).
>
> Secure Transport API:
>
> - provides close to nothing for manipulating certificates / keys => I
> had to write a minimal (DER-only) ASN.1 parser
>
> - only accepts certificates + keys .. in PKCS#12 form => I had some
> write some ASN.1 serialisation code, and a lot of PKCS#12 code (I
> absolutely hate that standard by now)
>
>
> 2. WHAT WORKS
>
> I am now getting to the point where a lot unit tests are passing.
>
> - QSslSocket works in client and in server mode
>
> - QSslCertificate works, with no external dependencies
>
> - QSslKey : ditto
>
>
> What still needs work:
>
>  - the build system needs to be updated to allow building the SSL
> classes, even when OpenSSL is not found
>
>  - QSslCertificate::isSelfSigned needs implementing
>
>  - QSslKey : serializing to a password-protected PEM does not work yet
>
>  - there is some duplicated code between the OpenSSL and Secure
> Transport backends
>
>  - QSslConfiguration : no work done yet
>
>
> 3. HOW TO GET IT
>
> As previously stated, my current work has been on OS X only, not actual
> iOS devices.
>
> 1/ Checkout the qssl-ios branch from
> https://qt.gitorious.org/qt/sharkys-qtbase on a OS X machine
>
> 2/ Apply the attached patch to fix / disable some QSslSocket unit tests
>
> 3/ Build it
>
> 4/ Run some unit tests
>
> 5/ Help fix the errors :)
>
>
> Cheers,
> Jeremy
>
>
> PS: no unfortunately I cannot make it to the contributor summit
>
> ___
> 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] Adding support for version number comparisons

[Richard Moore]

On 11 May 2014 02:16, Keith Gardner  wrote:

>
>1. Usually more condensed than the pre-release.
>2. Some projects experience multiple "releases" with the same version
>of software (1.0.0-2).
>3. Libjpeg and OpenSSL use a single letter to represent a level of
>security for some software (1.0.0g).
>
> openssl actually use a multi-letter suffix once it gets high enough. The
next version of openssl 0.9.8 will be 0.9.8za.

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

Re: [Development] RFC: Managing the Addition of New SSL Backends

[Richard Moore]

On 3 May 2014 22:38, Thiago Macieira  wrote:

> Em sáb 03 maio 2014, às 22:23:30, Richard Moore escreveu:
> > - A small but significant number of apps use client certificates.
> >
> > - A small but significant number of apps use server SSL sockets.
> >
> > - Very few applications use custom trust stores.
>
> I'd say there's a specific case where all three go together: if I am
> trying to
> verify a client certificate in a server application, I probably want to
> verify
> that the client certificate was issued by my CA.
>
> However, this case is uncommon and it's also unlikely to happen in a
> closed /
> controlled platform. Servers running SSL services are often not mobile
> applications, but it could happen for device-to-device communication in an
> Internet of Things world...
>
>
Yes, I think there are plenty of good reasons why people might do that, and
I'm not saying I think we should be aiming to have less capable backends.
I'm just trying to think of ways we can manage the fact that they're likely
to happen.

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

Re: [Development] RFC: Managing the Addition of New SSL Backends

[Richard Moore]

On 3 May 2014 22:42, Thiago Macieira  wrote:

> Em sáb 03 maio 2014, às 22:23:30, Richard Moore escreveu:
> > Simplifying the Cipher API
> > ==
> >
> > Currently, the QSslCipher API is pretty large. It's not simply the
> > code in the QSslCipher class itself, but also all the stuff in the
> > QSslConfiguration that defines the preferences. Instead, we could
> > offer a simplified API that all backends must offer. So, for example
> > we could have something as simple as High, Medium and Low! After all,
> > most people (including developers) don't know the trade-offs of the
> > different cipher suites anyway. We could also have a flag for perfect
> > forward secrecy since that is independent of the strength. It would
> > also be possible to have a setting like FIPS for people who care about
> > that.
>
> High, Medium and Low convey no meaning. Why should I choose "low security"?
>
>
What I was thinking was that this would specify if weak ciphers etc. should
be enabled. In general you'd end up with the strongest cipher the server
supports anyway, but if you'd set the security to 'low' then you'd be able
to connect to servers that only support low strength ciphers. ie. this
would be a setting for the minimum acceptable cipher strength.


> I'd say that we should either provide no choice in choosing the ciphers,
> or at
> most provide certain implementation details like allowing or disallowing
> ciphers without perfect forward secrecy and a choice of ciphers that are
> FIPS-
> certified.
>
>
That would be possible, yeah.

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

[Development] RFC: Managing the Addition of New SSL Backends

[Richard Moore]

Introduction


Qt provides a fairly powerful SSL API with support for a wide range of
uses - SSL clients and servers can both be created. It provides
extensive APIs for accessing information in SSL certificates,
information about ciphers etc. In addition to the basics, it also
includes built in support for more advanced features such as client
certificates, server name indication etc.

Since Qt 4.4 the SSL API has been based exclusively on a single
backend implemented using OpenSSL. This has worked well for a long
time, despite some pain caused by the regular source and binary
compatibility breakages that OpenSSL suffers from. The major downside
is that it can prove difficult for some users to install OpenSSL, and
that some platforms (I'm looking at you Apple) only provide old
versions. Unfortunately for legal reasons, the Qt project is unable to
bundle a copy of OpenSSL making it hard to address this weakness.

Recently, there have been some efforts to provide non-OpenSSL based
support for SSL in Qt. Currently, this consists of some minimal
support as a fallback on iOS that allows QNetworkAccessManager (QNAM)
to access HTTPS sites using NSURLConnection (by Morten Sovig), and the
start of some work to implement a real (as-in fully compatible with
the existing API) SSL backend using SecureTransport by Jeremy Laine. A
similar effort will also be required to add support for SSL on WinRT.

The current SSL API Qt offers is powerful but large making
implementing a full backend a significant undertaking. What I hope to
set out here are some ideas of how this can be made easier by
considering a set of modular capabilities that backends could
offer. This would mean that new backends could offer a subset of the
full API but would still be compatible with both each other and with
the current OpenSSL backend.

Use-Cases
=

- Most apps simply use QNAM.

- Many apps need to handle user exceptions to SSL connections that
  would otherwise error.

- Many applications use client SSL sockets.

- A small but significant number of apps use client certificates.

- A small but significant number of apps use server SSL sockets.

- Very few applications customise the set of ciphersuites used for
  SSL.

- Very few applications use custom trust stores.


Support for QNAM


It's obvious that to be useful, a backend must allow QNAM to make SSL
requests. It need not support the more advanced features such as
client certs, custom CAs, custom cipher suites etc.

In order to handle user exceptions, we need a way to signal the
errors. This means that QSslError would be required. Another option
might be to offer some pre-built UI component for this, but that has
the issue that a single component would probably not be a good fit to
many UIs.

Another issue is displaying the certificate to the user. The
QSslCertificate API is large, and whilst I think most backends would
be able to provide most (if not all) of the facilities this is still a
significant barrier. Instead, how about we allow QSslCertificate to be
used as an opaque type for most apps?  This could be done by providing
access to the platform native (or a Qt provided) certificate
dialog. This would reduce the requirements for the backend
substantially.

Simplifying the Cipher API
==

Currently, the QSslCipher API is pretty large. It's not simply the
code in the QSslCipher class itself, but also all the stuff in the
QSslConfiguration that defines the preferences. Instead, we could
offer a simplified API that all backends must offer. So, for example
we could have something as simple as High, Medium and Low! After all,
most people (including developers) don't know the trade-offs of the
different cipher suites anyway. We could also have a flag for perfect
forward secrecy since that is independent of the strength. It would
also be possible to have a setting like FIPS for people who care about
that.

Simplifying the Certificate API
===

Most applications only need minimal information from certificates - in
fact in many cases the only direct usage is to show the certificate to
the user. We could allow applications to do this by proving a method
to show a certificate dialog given a list of QSslCertificates, this
could either be the platform certificate dialog or one provided by the
Qt backend. If we did this then a backend could simply have stubs for
the current accessors (or we could define a minimal subset they should
provide).

Proposed Capabilities
=

* SSL Client

A backend offering this capability must offer the basic client-side
QSslSocket API.

* SSL Server

A backend offering this capability must offer the basic server-side
QSslSocket API.

* Client Certficates

A backend offering this capability must support the various client
cert methods in QSslConfiguration etc.

* Certificate

A backend offering this capability must support the QSslCertificate
API.

* Ciphers

A backen

Re: [Development] qDebug, qWarning, qCritical, qFatal in Qt source code

[Richard Moore]

On 3 May 2014 11:28, Kurt Pattyn  wrote:

> Hi,
>
> I would like to know if there are any guidelines about using qDebug and
> friends in Qt source code?
> Recently I had to remove qWarning statements from a submit (for very
> plausible reasons), but a quick search through qtbase revealed a lot of
> qWarning statements.
>
> So are there any rules of thumb?
>

qWarning - the developer writing an app using Qt has made an error in their
code that has lead to calling Qt with invalid values, for example
connecting to a slot that does not exist.

qDebug - when used in Qt itself, this is stuff to help with debugging of
Qt. Users of Qt will often have Qt itself built without them, so don't rely
on these messages to actually appear to people developing apps.

qFatal - something is so screwed we cannot continue. Prints a message then
aborts.

qCritical - similar to the above but doesn't abort.

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

Re: [Development] No SSL on iOS ?

[Richard Moore]

On 29 April 2014 12:13, Sorvig Morten  wrote:

> >> What would the best course of action be to add support for secure
> websockets
> >> on iOS?
> >
> > Probably to add a new QSslSocket backend that uses the Apple API.
>
> QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make
> sure you are aware of the scope of the project and remember you have to
> maintain it :)
>
>
I actually started thinking about how a smaller API for some of this could
look. Basically with the idea being that for many applications only a
subset of the full QSslXX apis mattered. If you want me to post my notes
(such as they are) then I'm happy to do so.


> Another option is to skip QSslSocket and implement a direct backend for
> QWebSocket using a native API, for example the SocketRocket project.
>
>
I'm not sure that the design of the QWebSocket module really allows this
kind of plugability. Perhaps Kurt can comment?

Cheers

Rich.


> I used this approach to implement an iOS backend for the QNAM rest API
> (using NSurlConnection).
>
> Morten
>
> ___
> 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] Question about Qt's future

[Richard Moore]

On 27 April 2014 22:31, Mark Gaiser  wrote:

> Actually, you can..
> http://css-tricks.com/a-couple-of-use-cases-for-calc/
>
> And even Internet Explorer has support for it:
> http://caniuse.com/#feat=calc
>
>
It's a variant of the expression() facility that IE has offered to CSS
since IE6. It's extremely useful for bypassing XSS filters. :-)

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

Re: [Development] QtQml value types

[Richard Moore]

On 25 April 2014 11:51, Alberto Mardegan wrote:

> For instance, I would like to have a GeoPoint type with "latitude" and
> "longitude" properties; if I exposed it as a QVariantMap, I wouldn't be
> able to prevent the QML code from doing stuff like:
> p.latitude = 60
> p.longitde = 10 // note the typo
>

An approach like http://qt-project.org/doc/qt-4.8/qscriptclass.html would
allow this to be enforced.

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

Re: [Development] Qt-Designer sources ?

[Richard Moore]

On 22 April 2014 16:20, Martin Koller  wrote:

> Where do I find the sources for Qt Designer ?
> Or is there no longer a stand-alone designer application in Qt5 as was in
> Qt4 ?
>

https://qt.gitorious.org/qt/qttools/source/e7b791c8bb5e64a4c786bf370b10366815af704f:src/designer

Cheers

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

[Development] Static analysis of Qt

[Richard Moore]

http://www.viva64.com/en/b/0251/

I've fixed a few of the copy-paste errors, but I've not gone through the
whole list:

https://codereview.qt-project.org/#change,83763
https://codereview.qt-project.org/#change,83764
https://codereview.qt-project.org/#change,83765
https://codereview.qt-project.org/#change,83766

Cheers

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

Re: [Development] Nominating Jake Petroules as approver

[Richard Moore]

+1


On 15 April 2014 18:13, Thiago Macieira  wrote:

> Hello
>
> I'd like to nominate Jake Petroules as approver. He's been very active in
> the
> Mac port in the recent months, helping out with issues like adding support
> for
> the CoreFoundation types in QtCore, among other tasks. He's located in the
> US
> West Coast, which helps me with reviews in late afternoons.
>
> Here's a link to his submissions
>
> https://codereview.qt-project.org/#q,owner:jake.petrou...@petroules.com,n,z
>
> Reviews:
>
> https://codereview.qt-project.org/#q,reviewer:jake.petrou...@petroules.com,n,z
>
> And dashboard:
>  https://codereview.qt-project.org/#dashboard,1000530
>
> --
> 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] [API Change] New authentication method in QNetworkAccessManager

[Richard Moore]

On 9 March 2014 20:13, Kurt Pattyn  wrote:

>
> On 09 Mar 2014, at 21:02, Giuseppe D'Angelo  wrote:
>
> > On 9 March 2014 15:10, Kurt Pattyn  wrote:
> >> Also, the connection between the authenticationRequired signal and the
> slot
> >> must be a direct connection.
> >
> > IIRC SSL sockets had the same "issue" when SSL errors are raised. Has
> > it been solved there? How?
> AFAIK, it has not been solved. The problem is the same.
>

It has been partially solved, in recent versions you can set the socket to
pause when ssl errors occur which avoids the need to use a nested event
loop, see https://codereview.qt-project.org/#change,13834 We want this to
be supported for authentication and also for ssl when there are no errors.
It is being tracked as
QTBUG-19032
.

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

[Development] CI Broken for 4.8

[Richard Moore]

Hi,

CI appears to be broken for 4.8, for example the following changes
(separate CI runs) have failed on the same tests even though one is just a
doc fix:

https://codereview.qt-project.org/#change,79247
https://codereview.qt-project.org/#change,78289

It appears to the macos node that is stuck. Last integration was Tuesday,
February 25, 2014 21:47:56.

Anyone able to look into this?

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

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Richard Moore]

On 12 February 2014 14:44, Konrad Rosenbaum  wrote:
> On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote:
>> On 11 Feb 2014, at 19:14, Thiago Macieira  wrote:
>> > Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu:
>> >> http://channel9.msdn.com/Events/GoingNative/2013/rand-Considered-Harmful
>> >
>> > No doubt. And we should have a more secure generator, at least until we
>> > can rely on std::random.
>>
>> We can always 'duplicate' some code from the std::random library :-)
>> How 'secure' should this be? Is a Mersenne-Twister for instance 'secure'
>> enough?
>
> Secure enough for a simple Monte-Carlo style simulation? Yes, definitely,
> that's what it was designed for.
>
> Secure enough for the initial WebSocket implementation in Qt 5.3? Well, not
> really, but let's go with it (qrand) and fix it in 5.4.

It's really fine for this use-case as I said in my earlier email. Qt
does not provide any form of sandbox - all code that can use the
websockets classes is either 1) trusted or 2) must be secured by a
sandbox provided by the application. Given this, the only purpose of
the masking in Qt is to prevent accidental problems due to triggering
the class of problems that lead to request smuggling flaws in proxies.
Making the mask change is really only necessary so that you won't get
a consistent failure (since the second time the mask will be
different). This is a completely different environment to use the use
of websockets in a browser where untrusted code is being run and could
potentially exploit request smuggling to by-pass SOP, which is why
they need secure random numbers and we do not.

It would be nice to have a secure random number source in Qt, but
that's a completely different question.

Regards

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

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Richard Moore]

On 30 January 2014 14:22, Koehne Kai  wrote:
>
>
>> -Original Message-
>> From: development-bounces+kai.koehne=digia@qt-project.org
>> [...]
>> Again, only 3rd party untrusted content matters here and for that you need a
>> sandbox.
>
> I'm not entirely sure '3rd party untrusted content' in the Qt process is 
> needed for these sort of attacks.
>
> That's how I understood it so far:
> 1. the attack vector is web proxy poisoning. That is , all it takes is an 
> attacker that
> a) can access a remote under his control through the same proxy as the target 
> (or gets some user behin the proxy to access the remote)
> b) knows how the websocket request will look like
> c) Manages to poison the proxy to cache a poisonous answer for the request
>
> The hashing stuff etc tries to prevent b), but strong entropy is required so 
> that the attacker can't just 'guess' future requests e.g. from monitoring 
> previous requests.
>
> Correct me if I'm wrong, but that scheme will work independent of whether the 
> user / app itself runs untrusted content etc.
>

Yes it would... except that if the attacker can execute arbitrary code
then he doesn't have to use this API - he can just do the attack. The
masking comes in useful when the attacker is sandboxed so can only
perform the attack using the subset of facilities exposed to him - in
this case the websockets api.

Cheers

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

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Richard Moore]

On 30 January 2014 12:26, Konrad Rosenbaum  wrote:
> On Wednesday, Wednesday 29 January 2014 at 21:25, Richard Moore wrote:
>
>> Sorry but most of this is irrelevant to Qt. Qt applications and QML
>
>> applications are not like Javascript in a browser - they're already
>
>> trusted and not sandboxed at all.
>
>
>
> I know a few Qt applications that match exactly the scenario that masking is
> supposed to help against, to name just two obvious ones: Konqueror, Snowshoe

Those use webkit which has a separate implementation of websockets.
They do not use this module.

>
> A few of my own apps, while not browsers, allow user generated scripts (not
> necessarily JavaScript) and allow the scripts some access to HTTP. Some of
> those scripts are not fully trusted either - they have severe limits in what
> they can do.

User-generated scripts aren't the problem - those are presumably
trusted (or if they're not then you must have your own sandbox
implementation).

>> For Qt, we just need to ensure that
>> the masking works (ie prevents a non-malicious app accidentally
>> triggering a buggy proxy).
>
> I am not overly concerned with QML and scripts programmed by the same people
> who did the C++ work. You can't defend against them anyway (except by not
> using the app).
>
> I am concerned with user generated content that has access to HTTP and
> Websockets in some scripted way.

Again, only 3rd party untrusted content matters here and for that you
need a sandbox.

>
> But I would agree that the percentage of Qt applications for whicht this is
> critical is very low and I would not waste too much effort on this for the
> initial release. It might even be argued that the effort should be shifted
> to apps that actually need secure random by implementing a weak virtual
> function and allowing the user to override it.
>

Peppe has previously started looking at adding a secure random source
(in addition I provide one in the certificate addon). There are enough
use cases that I think we'll include one in Qt at some point.

Cheers

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

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Richard Moore]

Sorry but most of this is irrelevant to Qt. Qt applications and QML
applications are not like Javascript in a browser - they're already
trusted and not sandboxed at all. For Qt, we just need to ensure that
the masking works (ie prevents a non-malicious app accidentally
triggering a buggy proxy).

Cheers

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

Re: [Development] websockets (was RE: Qt 5.3 Feature freeze is coming quite soon...)

[Richard Moore]

On 26 January 2014 19:23, Kurt Pattyn  wrote:
>> 2. When sending data from client to server (not the other way)
>> The client generates a 32-bit random number.
>> This random number is stored in plain text in the header of each frame.
>> The data is XOR-ed with that 32-bit random number.
>>
>> The server takes the 32-bit random number from the header and XORs it
>> with the payload to get to the original data.
>>
>> I really fail to see what the intention is of this mechanism. I really
>> fail to see what could make this communication ‘secure’.

The aim of the masking is to prevent request splitting and smuggling
attacks when going through proxies. It prevents an application from
being to trick proxies into beginning a new request that does
something different to the one intended.

https://www.owasp.org/index.php/HTTP_Request_Smuggling

Cheers

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

Re: [Development] Remove OSX 10.6 Build?

[Richard Moore]

>> XP was introduced in 2001. It’s still supported. Mac OS 10.6 was
>> introduced in 2009. I understand the desire to get rid of the messiness
>> under the hood, but I think it should be considered that it cuts out users
>> on hardware platforms not so much up to date.
>
>
> Right but the difference is that Microsoft was not very good at making a
> decent successor of XP which made most of the people stick with XP.
>
>
>  It’s not just that. This also has to do with the cost of upgrading
> hardware. Charts describing OS destribution, top contributors mentioned):
>
> Worldwide: http://gs.statcounter.com/#os-ww-monthly-201212-201312-bar (Win7:
> 52%, XP: 22%, Mac OS: 7%)
>
> Denmark: http://gs.statcounter.com/#os-DK-monthly-201212-201312-bar (Win7:
> 53%, Mac OS: 16%, iOS: 8.5%)
> Denmark is a country with big purchasing power. Win XP is almost gone here,
> below Mac OS and iOS, units usually associated with higher price.
>
> China: http://gs.statcounter.com/#os-CN-monthly-201212-201312-bar (XP: 56%,
> Win7: 36%, Win8: 2%)
> XP dominates here. One might suspect the cause being less general buying
> power. Note the lack of Apple hardware in the top.
>
> Cuba: http://gs.statcounter.com/#os-CU-monthly-201212-201312-bar (WP: 51%,
> Win7: 32%,  Linux: 6.7%
> Same here. Note the sudden appearance of Linux. Many Linux distros runs well
> on lower powered hardware. I doubt that Cubans are die hard Linux fans in
> general.
>
> I don’t think I’m interpreting too much from the above by stating that the
> popularity of older OS versions are dependent on buying power and geography,
> not just the existence of replacement candidates.

If you're going to make a commercial argument based on 'buying power'
then you also need to factor in how many of those installations have
actually paid for their licenses. Or more specifically, how many of
them are going to pay to buy applications developed in Qt. As an open
source developer I don't really care, but we have limited resources so
a target platform that isn't going to offer a return for commercial
developers /or/ open source developers isn't sustainable.

Cheers

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

Re: [Development] Qt 5.3 Feature freeze is coming quite soon...

[Richard Moore]

On 17 January 2014 19:49, Kurt Pattyn  wrote:
> So, based on the feedback, can everybody agree on QtWebSockets being an 
> add-on?
> It keeps the core as is, and provides an opt-in for applications that need it.

+1 from me. I think it's a good addition to the framework.

Rich.

>
> Cheers,
>
> Kurt
>
>> On 17 Jan 2014, at 12:25, Richard Moore  wrote:
>>
>>> On 17 January 2014 07:54, Knoll Lars  wrote:
>>>
>>> From a feature point of view it would fit best into Qt Network. But it's a 
>>> sizeable piece of code added to Qt Network. Do you have any numbers on how 
>>> this changes the size of Qt Network?
>>>
>>> Peter and Rich, and comments from your side?
>>
>> Given that the websocket code contains both C++ networking stuff and
>> also QML it cannot all go into qt network as this would introduce a
>> circular dependency on the qtdeclarative module. This would mean
>> splitting it into two one part in qt network and another in qt
>> declarative which I think would be a bit confusing for users.
>>
>> On the other hand as an addon module the dependency problem is gone
>> and it can be available as a single self-contained module (with
>> unified documentation) which I suspect would be easier on those using
>> the module. I don't think adding QT += websockets to the pro file
>> would be a barrier for adoption.
>>
>> Given the above (and ignoring the issue of code-size etc.) my initial
>> feeling is that an addon module is probably a better choice for users
>> of the module.
>>
>> Cheers
>>
>> Rich.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Fwd: Qt 5.3 Feature freeze is coming quite soon...

[Richard Moore]

Resend from the right email address.

-- Forwarded message --
From: Richard Moore 
Date: 17 January 2014 11:25
Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
To: Knoll Lars 
Cc: Steve Gold , Kurt Pattyn
, "development@qt-project.org"
, Heikkinen Jani
, "releas...@qt-project.org"
, Thiago Macieira
, Peter Hartmann 


On 17 January 2014 07:54, Knoll Lars  wrote:
>
> From a feature point of view it would fit best into Qt Network. But it's a 
> sizeable piece of code added to Qt Network. Do you have any numbers on how 
> this changes the size of Qt Network?
>
> Peter and Rich, and comments from your side?
>

Given that the websocket code contains both C++ networking stuff and
also QML it cannot all go into qt network as this would introduce a
circular dependency on the qtdeclarative module. This would mean
splitting it into two one part in qt network and another in qt
declarative which I think would be a bit confusing for users.

On the other hand as an addon module the dependency problem is gone
and it can be available as a single self-contained module (with
unified documentation) which I suspect would be easier on those using
the module. I don't think adding QT += websockets to the pro file
would be a barrier for adoption.

Given the above (and ignoring the issue of code-size etc.) my initial
feeling is that an addon module is probably a better choice for users
of the module.

Cheers

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

Re: [Development] Coding style proposal

[Richard Moore]

On 2 January 2014 18:33, Jiergir Ogoerg  wrote:
> It's not for documentation purposes (not for those using Qt to create
> apps), but for those working with the Qt code.
> Currently, if you're coding a method you put it virtually anywhere in the 
> file.
> If you have 30 methods they're put alphabetically in the docs - and
> it's not about the docs,
> when you dig the source code they're put randomly like spaghetti.

Having setFoo() miles away from foo() would make it much harder for me
as a developer.

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

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 30 December 2013 16:07, Mandeep Sandhu  wrote:
 So I guess having body in the 3xx response will not be all that unusual.
>>>
>>> It will be.
>>
>> Actually, it's extremely common - here's a default apache 301 for example:

[snip]
> I guess the body is provided for clients who can't or intentionally
> won't, do a HTTP redirect. In that case the message in the body is
> shown to the user to do a manual redirect.

Yes

>
> In any case, coming back to the original question, how should the
> downloadProgress signal behave? Have it reset each time on a redirect
> (as the total bytes can possibly change across redirects)?

Since we know immediately that we're being redirected we can simply
wait until we get a non-redirecting response before we start emitting
the progress signals. We just need to (internally) ensure that we've
read the body from the redirect response, the user of QNAM doesn't
need to care.

Cheers

Rich.

>
> I guess this is also the only way to do it as we don't know in advance
> how many redirects are going to happen and what content they may
> carry.
>
> -mandeep
>
>>
>> Cheers
>>
>> Rich.
>> ___
>> 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] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 30 December 2013 11:25, Thiago Macieira  wrote:
> On segunda-feira, 30 de dezembro de 2013 11:23:29, Mandeep Sandhu wrote:
>> > Maybe rare for URL shorteners. Internal redirects inside a web site or
>> > group of sites are a different matter: call me an old-grumpy-Mosaic-user
>> > if you like, but I usually add a body of the "if you are not redirected
>> > automatically click here" -type when I program redirects, I usually even
>> > include a meta tag - you never know how stupid the configuration on the
>> > server is where your script runs.
>>
>> Oh yes! Good point...I've seen websites do this  couple of times
>> (though I was under the impression that it was done using some sort of
>> client-side timer to do the actual redirect).
>>
>> So I guess having body in the 3xx response will not be all that unusual.
>
> It will be.

Actually, it's extremely common - here's a default apache 301 for example:

monster:/home/rich/src/wireshark # telnet xmelegance.org 80
Trying 80.68.89.8...
Connected to xmelegance.org.
Escape character is '^]'.
GET /devel HTTP/1.1
Host: xmelegance.org
Content-Length: 0

HTTP/1.1 301 Moved Permanently
Date: Mon, 30 Dec 2013 15:13:21 GMT
Server: Apache
Location: http://xmelegance.org/devel/
Content-Length: 236
Content-Type: text/html; charset=iso-8859-1



301 Moved Permanently

Moved Permanently
The document has moved http://xmelegance.org/devel/";>here.


Cheers

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

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 26 December 2013 17:10, Mandeep Sandhu  wrote:
> On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore  wrote:
>> On 26 December 2013 13:11, Thiago Macieira  wrote:
>>> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
>>>> We could emit download progress for each intermediate request, but
>>>> won't that look strange to a user as the bytes received & _possibly_
>>>> bytes total values will keep changing across these requests? Or is
>>>> that acceptable given the user knows that we're making multiple
>>>> requests on its behalf?
>>>
>>> There is no downloadProgress for any intermediate requests. We know that 
>>> we're
>>> redirecting before we get the first byte of data out of the server. At that
>>> point, we can abandon the QHttpNetworkReply and move on to the next already.
>>
>> Hmm true, though we'll have to make sure we read any body provided
>> rather than just abandon the request or we can't reuse the connection.
>
> Reuse of connection will also depend on where we're being redirected
> to. If it's a different domain/server altogether then we'll have to
> make a new connection (eg: how URL shortening services work).

That's true, but misses the point. We retain and reuse connections (up
to 6 per server). We might well end up using a new one (or reusing an
old one) after a redirect but we can't leave the original one in an
inconsistent state. For example, if a page links to 10 images and each
image request is actually a redirect to where the image really lives
then we'd reuse the connections to the first server for the later
image requests.

Cheers

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

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 26 December 2013 13:11, Thiago Macieira  wrote:
> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
>> We could emit download progress for each intermediate request, but
>> won't that look strange to a user as the bytes received & _possibly_
>> bytes total values will keep changing across these requests? Or is
>> that acceptable given the user knows that we're making multiple
>> requests on its behalf?
>
> There is no downloadProgress for any intermediate requests. We know that we're
> redirecting before we get the first byte of data out of the server. At that
> point, we can abandon the QHttpNetworkReply and move on to the next already.

Hmm true, though we'll have to make sure we read any body provided
rather than just abandon the request or we can't reuse the connection.

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

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 26 December 2013 12:45, Mandeep Sandhu  wrote:
>>> Your thoughts?
>>
>> The download progress signal will have to be emitted for the
>> intermediate requests. Things like operation() and url() are stored in
>> the request object which can't be changed by the QNAM at all. If
>> people want all the details then they must implement their own
>> redirection support. The built in support can only cover the simple
>> cases.
>
> We could emit download progress for each intermediate request, but
> won't that look strange to a user as the bytes received & _possibly_
> bytes total values will keep changing across these requests? Or is
> that acceptable given the user knows that we're making multiple
> requests on its behalf?

Yes. since the app has to opt-in to get redirection support we can
require that the app understands that this can occur.

Cheers

Rich.

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

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 25 December 2013 07:54, Mandeep Sandhu  wrote:
>>>
>>> 3. QNetworkReply stores both, the original as well as the final url.
>>
>> What about the intermediate ones in a chain of redirects?
>>
>
> Another question that springs to mind is what should the QNetworkReply
> object returned to the user reflect while the redirects are going on?
>
> Eg: What should the download progress signal show? should we keep
> emitting it for intermediate requests too? Similarly, what should
> other APIs like url(), operation() show, info about the 1st or the
> final request?
>
> Your thoughts?

The download progress signal will have to be emitted for the
intermediate requests. Things like operation() and url() are stored in
the request object which can't be changed by the QNAM at all. If
people want all the details then they must implement their own
redirection support. The built in support can only cover the simple
cases.

>
> If this gets unnecessarily complex to be done from within the QNAM
> framework, maybe we can have some sort of a 'wrapper' class handling
> redirects using QNR's public APIs. We could possibly keep such a class
> in the qt-solutions repository if needed.

That's possible, but it would be nicer to have something built-in.

>
> Oh and Merry X'mas everyone! :)

And to you!

Rich.

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

Re: [Development] Proposal for allowing handling of HTTP redirects in QNAM

[Richard Moore]

On 24 December 2013 07:57, Mandeep Sandhu  wrote:
> Hi All,
>
> Few days back I stumbled upon this task:
> https://bugreports.qt-project.org/browse/QTBUG-8232
>
> "QNetworkAccessManager should support redirection"
>
> I think this is a useful feature that can be added to QNAM as it makes
> the life of a developer easy.
>
> I went through all the comments in the task page, libcurl
> documentation and also saw how some other libraries, like Python's
> urllib, handle redirection.
>
> I'm collating all that info here as a proposal for new functionality
> to QNAM and friends:
>
> 1. Allow handling of redirects at both global (QNAM) and per request
> (QNetworkRequest) level. Per request setting overrides global setting.
> Default will be to NOT handle redirects.
>
> 2. New "redirected(QUrl)" signal to be emitted in case auto-redirects
> are enabled and a redirection occurs.

This interface wouldn't be enough to let you distinguish between the
different types of redirect, though tbh I'm not sure that matters.

>
> 3. QNetworkReply stores both, the original as well as the final url.

What about the intermediate ones in a chain of redirects?

> 4. Allow setting of "max redirect" to avoid infinite redirections.
>
> 5. Allow a way to specify which protocols are allowed on redirects.
> Eg: curl by default does not redirect to "file" and "scp" protocols.

I don't think that should be offered. We pretty much concluded that
same-protocol redirects were okay, as were http -> https but others
were a mine field. https->http is one that I'm still unsure of since
it's one we see in real life, but has potential risks. If an app needs
detailed control (eg. as a browser does) then it should implement the
handling itself. QNAM should only handle the simple case.

>
> 6. Allow a way to specify redirect behaviour for POST requests. Eg: if
> a 301 is returned, the RFC states that the user agent MUST NOT change
> it to a GET request automatically.

IIRC the RFC is wrong or at least incomplete here and does not
describe actual behaviour of browsers. See
http://en.wikipedia.org/wiki/Post/Redirect/Get for more details.


> 7. New error code in QNetworkReply to indicate "too many redirects" error.
>
> The last update on this task was more than a year back. So I'm not
> sure if someone's already worked on it or if it's been abandoned due
> to some issue.
>
> I was wondering if a patch for it will be acceptable?

Sure, however it's quite involved. From inside the http backend you
need to start a new request meaning there's not a 1:1 mapping between
user requests and the internal ones. This is similar to what happens
with proxy auth etc. so you should look at the code that implements
that for inspiration.

Cheers

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

Re: [Development] [Interest] there should be a function to allow follow redirections

[Richard Moore]

On 13 December 2013 12:53, iMath <2281570...@qq.com> wrote:
> The Network Access API does not by default follow redirections, ok ,but
> there should be a function to allow follow all redirections.
> Although we can check if there is a redirect with the
> QNetworkRequest::RedirectionTargetAttribute attribute,this is ok if there is
> only one redirection with one url,but if there are many redirections from
> one url ,it would be cumbersome to follow all redirections by this way .
> it would be better to have a function like setFollowRedirections(bool) to
> allow use to do this ,for security ,setFolloRedirections(False) could be the
> default .

This is a known issue, see https://bugreports.qt-project.org/browse/QTBUG-8232

Regards

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

Re: [Development] QML and JavaScript extensions

[Richard Moore]

On 15 November 2013 19:51, Alan Alpert <4163654...@gmail.com> wrote:
> On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer  wrote:
>> On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote:
>>
>> I also wouldn't consider widgets to be deprecated, at least not yet. And
>> nicely use QML with widgets as the UI elements, it is not replacing one with
>> the other either (though you probably meant QtQuick when you wrote QML 
>> there).
>
> Yeah, QML doesn't deprecate widgets - it deprecates .ui files because
> now you can construct your widget UIs in QML :D . Long ago we
> discussed deprecating widgets because Nokia wanted to reallocate those
> development resources to QML/QtQuick, but thankfully open governance
> swooped in and saved the day.

The idea that QML deprecates ui files is frankly utter rubbish. UI
files offer many advantages over QML - decent widgets, keyboard
navigation, stability, faster coding for the common case in non-mobile
applications (to name just a few of them). There's nothing wrong with
QML, there's also nothing wrong with UI files, they just serve
different use cases.

Regards

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