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] 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 <richmoor...@gmail.com> 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" <lars.kn...@qt.io> 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 <tcanabr...@kde.org> 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 <kai.koe...@qt.io> 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 <lars.kn...@qt.io>
> > Cc: Thiago Macieira <thiago.macie...@intel.com>; Qt development mailing
> > list <development@qt-project.org>
> > 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 <lars.kn...@qt.io> wrote:

>
> > On 7 Mar 2017, at 21:54, Thiago Macieira <thiago.macie...@intel.com>
> 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 <marc.m...@kdab.com> 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 <marc.m...@kdab.com> | 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] 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 <richmoor...@gmail.com>
Date: 9 December 2015 at 17:22
Subject: Re: [Development] RFF: nullptr rules
To: "development@qt-project.org" <development@qt-project.org>




On 9 December 2015 at 15:14, Marc Mutz <marc.m...@kdab.com> 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 lars.kn...@theqtcompany.com 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] Playground request: qtmirserver

[Richard Moore]

On 10 August 2015 at 10:01, Paul Olav Tvete paul.tv...@theqtcompany.com
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 jani.heikki...@theqtcompany.com
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 mik...@krautz.dk 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 denis.shien...@gmail.com 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 j...@kde.org 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 6s. 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

[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 21 February 2015 at 18:38, Thiago Macieira thiago.macie...@intel.com
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 22 February 2015 at 17:50, Jeremy Lainé jeremy.la...@m4x.org wrote:

  On 02/22/2015 06:42 PM, Richard Moore wrote:



 On 22 February 2015 at 17:39, Jeremy Lainé jeremy.la...@m4x.org 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é jeremy.la...@m4x.org 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 22 February 2015 at 20:08, Sorvig Morten morten.sor...@theqtcompany.com
wrote:


  On 22 Feb 2015, at 18:50, Jeremy Lainé jeremy.la...@m4x.org wrote:
 
  On 02/22/2015 06:42 PM, Richard Moore wrote:
 
 
  On 22 February 2015 at 17:39, Jeremy Lainé jeremy.la...@m4x.org
 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 21 February 2015 at 18:38, Konstantin Ritt ritt...@gmail.com wrote:

 2015-02-21 22:05 GMT+04:00 Richard Moore r...@kde.org:


 On 21 February 2015 at 17:34, Konstantin Ritt ritt...@gmail.com wrote:

 2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org:

 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

[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

Re: [Development] SSL Plans for Qt 5.6

[Richard Moore]

On 21 February 2015 at 17:34, Konstantin Ritt ritt...@gmail.com wrote:

 2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org:

 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] 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 lars.kn...@theqtcompany.com 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]

On 26 January 2015 at 19:28, Marc Mutz marc.m...@kdab.com 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]

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(QListQSslCertificate());
socket2-connectToHostEncrypted(host, 443);
QVERIFY(!socket2-waitForEncrypted());

Grr.

Rich.


On 26 January 2015 at 20:54, Richard Moore r...@kde.org wrote:



 On 26 January 2015 at 19:28, Marc Mutz marc.m...@kdab.com 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 thiago.macie...@intel.com
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 thiago.macie...@intel.com
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 26 December 2014 at 21:12, Thiago Macieira thiago.macie...@intel.com
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] QSsl: finer-grained protocol selection

[Richard Moore]

On 27 December 2014 at 11:44, Mikkel Krautz mik...@krautz.dk wrote:

 On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore r...@kde.org wrote:
  On 26 December 2014 at 21:12, Thiago Macieira thiago.macie...@intel.com
 
  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] 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 thiago.macie...@intel.com
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 3 September 2014 20:25, Thiago Macieira thiago.macie...@intel.com
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] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method.

[Richard Moore]

On 4 September 2014 10:29, Allan Sandfeld Jensen k...@carewolf.com wrote:

 On Thursday 04 September 2014, Richard Moore wrote:
  On 3 September 2014 20:25, Thiago Macieira thiago.macie...@intel.com
 
  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] Updating the licence policy for Qt Project

[Richard Moore]

On 27 August 2014 14:55, Oswald Buddenhagen oswald.buddenha...@digia.com
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 r...@kde.org
Date: 15 July 2014 22:55
Subject: Re: [Development] Nominating Milian Wolff as approver
To: Gladhorn Frederik frederik.gladh...@digia.com


He isn't already? +1

Rich.



On 15 July 2014 21:08, Gladhorn Frederik frederik.gladh...@digia.com
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 r...@kde.org 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 friedemann.kle...@digia.com 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.) bstot...@ford.com 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 kreios4...@gmail.com wrote:

 On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann simon.hausm...@digia.com
 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é jeremy.la...@m4x.org 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 kreios4...@gmail.com 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:42, Thiago Macieira thiago.macie...@intel.com 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

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

[Richard Moore]

On 3 May 2014 22:38, Thiago Macieira thiago.macie...@intel.com 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] qDebug, qWarning, qCritical, qFatal in Qt source code

[Richard Moore]

On 3 May 2014 11:28, Kurt Pattyn pattyn.k...@gmail.com 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

[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 

Re: [Development] No SSL on iOS ?

[Richard Moore]

On 29 April 2014 12:13, Sorvig Morten morten.sor...@digia.com 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 mark...@gmail.com 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 ma...@users.sourceforge.netwrote:

 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 kol...@aon.at 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

Re: [Development] [API Change] New authentication method in QNetworkAccessManager

[Richard Moore]

On 9 March 2014 20:13, Kurt Pattyn pattyn.k...@gmail.com wrote:


 On 09 Mar 2014, at 21:02, Giuseppe D'Angelo dange...@gmail.com wrote:

  On 9 March 2014 15:10, Kurt Pattyn pattyn.k...@gmail.com 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-19032https://bugreports.qt-project.org/browse/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 kon...@silmor.de wrote:
 On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote:
 On 11 Feb 2014, at 19:14, Thiago Macieira thiago.macie...@intel.com 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 12:26, Konrad Rosenbaum kon...@silmor.de 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]

On 30 January 2014 14:22, Koehne Kai kai.koe...@digia.com 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]

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 pattyn.k...@gmail.com 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 pattyn.k...@gmail.com 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 richmoor...@gmail.com wrote:

 On 17 January 2014 07:54, Knoll Lars lars.kn...@digia.com 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 richmoor...@gmail.com
Date: 17 January 2014 11:25
Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
To: Knoll Lars lars.kn...@digia.com
Cc: Steve Gold steveg2...@gmail.com, Kurt Pattyn
pattyn.k...@gmail.com, development@qt-project.org
development@qt-project.org, Heikkinen Jani
jani.heikki...@digia.com, releas...@qt-project.org
releas...@qt-project.org, Thiago Macieira
thiago.macie...@intel.com, Peter Hartmann phartm...@blackberry.com


On 17 January 2014 07:54, Knoll Lars lars.kn...@digia.com 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 f35f22...@gmail.com 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 mandeepsandhu@gmail.com 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 25 December 2013 07:54, Mandeep Sandhu mandeepsandhu@gmail.com 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 26 December 2013 12:45, Mandeep Sandhu mandeepsandhu@gmail.com 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 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com 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 17:10, Mandeep Sandhu mandeepsandhu@gmail.com wrote:
 On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore r...@kde.org wrote:
 On 26 December 2013 13:11, Thiago Macieira thiago.macie...@intel.com 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 24 December 2013 07:57, Mandeep Sandhu mandeepsandhu@gmail.com 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 kevin.kram...@kdab.com 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

[Development] Maintainership of QtNetwork

[Richard Moore]

Hi All,

As some of you may know, Shane has a new job and therefore has a lot
less time to spend on QtNetwork. He, Peter and I have discussed how we
should maintain the module in the future. What we're proposing is that
Peter and I take over as joint maintainers since neither of us has the
time to keep on top of things alone. Anyone looking to help out in
this area should feel free to drop us a mail.

Cheers

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

Re: [Development] Maintainership of QtNetwork

[Richard Moore]

Hi All,

I think there's a valid question in who gets to be the arbiter should
Peter and I disagree on something, however between Peter, Shane and I
we've been working with pretty much this model anyway - I can't
imagine that any of us would allow something through that one of the
others disagreed with. In a situation like this, then we always have
Lars as a tie breaker with his chief maintainer hat on.

I'd guess that any likely tie in this situation would be more along
the lines of /should/ we support a feature rather than how the feature
is supported. I don't see this being a problem based on the way we've
managed to run stuff for the last couple of years, but if we really
need a designated QtNetwork tie breaker, then really either of us
could be that person. It seems a but academic to me since Peter, Shane
and I have been collaborating on the network stack since opengov
started, so this isn't a new team or any kind of dramatic change.

I don't mind how people want this to be handled. Joint maintainership
or a designated tie breaker is fine with me.

Cheers

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

Re: [Development] #error for unreleased MSVC versions

[Richard Moore]

If it's a configure option, we should note if this was done in the
binary so that we can know to ignore the inevitable bug reports.

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

Re: [Development] Qt 5.2 Testing

[Richard Moore]

That's a bug in the design of Unity. See
http://www.howtogeek.com/68119/how-to-bring-app-icons-back-into-unitys-system-tray/

Regards

Rich.

On 14 October 2013 13:34, Jiergir Ogoerg f35f22...@gmail.com wrote:
 Hi,
 Is system tray supposed to work under Ubuntu Unity? cause it's been broken
 ever since Qt 5.0 I guesss, including the recent Qt 5.2 beta release, the
 problem is: the tray icon doesn't show up - but it does show up (i.e. works)
 in Kubuntu (same computer, logging out of Unity, logging in into
 kubuntu-desktop).
 For the record - the system tray in kde4/qt4 works ok under Ubuntu/Unity.

 Testing on amd64 Ubuntu 13.10 with all daily updates installed.
 I only found this bug reported though I'm not sure it addresses this
 problem:
 https://bugreports.qt-project.org/browse/QTBUG-30079

 To be more specific this code works in Kubuntu but doesn't in Ubuntu/Unity
 (amd64 13.10 daily):

 int main(int argc, char *argv[])
 {
 QApplication app(argc, argv);
 gst_init(NULL, NULL);

 quap::ui::Win win;

 QIcon icon(/home/fox/icon.png);
 QSystemTrayIcon tray_icon(icon, win);
 tray_icon.setVisible(true); // WON'T SHOW UP under Ubuntu/unity

 win.show();

 return app.exec();
 }

 Kind Regards

 ___
 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] QNetworkRequest: allow overriding connect host

[Richard Moore]

On 10 May 2013 11:32,  shane.kea...@accenture.com wrote:
 QHostInfo has a short-lived cache, so it should work.

 Yes, but relying on implementation details isn't a good idea.

 I thought the proposed feature could be more generally useful, for example 
 using test live servers that are configured exactly as the live server so 
 they have a DNS address not matching the SSL certificate.

That's something we have to deal with very frequently at work. I'd be
happy to review a feature that offered this.

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

Re: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version

[Richard Moore]

On 25 April 2013 16:05, Thiago Macieira thiago.macie...@intel.com wrote:
 On quinta-feira, 25 de abril de 2013 11.10.56, Diego Iastrubni wrote:
 On Thu, Apr 25, 2013 at 9:29 AM, Sébastien Fricker
 fric...@froglogic.comwrote:
   Tony,
 
  why not also providing a VMWare image ready to use?
  Regards,

 Do you want the cake, or the recipe? This is a FOSS community, we want the
 recipe :)

 I thought the rule was I want the cake and eat it too... :-)

 Anyway, a pre-built image is much bigger to download than a set of Puppet
 rules.

The more serious issue with a pre-built image is keeping it updated.
The puppet scripts will do that automatically. The test server isn't
(or at least should not be) static, as new features and tests can
require new services etc. be added. If a VM image was provided it
would become out of date, and needed to be redownloaded etc.

Regards

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

[Development] Setting a Minimum Support OpenSSL Version

[Richard Moore]

Currently, the ssl support in Qt aims to support a wide range of
openssl version but the actual set isn't really defined. The platforms
vary too - windows doesn't bundle openssl so users are expected to add
their own, linux generally has a reasonably modern version, macos
includes openssl but only a really old version with a macos ports
version being required for anything recent. On macos the library is
deprecated too, so we can't expect apple to actually update it. We
can't really continue like this, I think it's clear that we need to
set a minimum support version, the only question is which?

1) We could say we'll set the minimum to the version macos bundles.

Since openssl has been deprecated on mac, this version would have the
advantage of providing a fixed target, but it will get increasingly
difficult to support. I would also not be surprised should it be
removed from the platform fairly soon since it's largely been replaced
by a mac specific library. Personally, I'm not going to waste my time
on a version this old, but if there's demand then maybe someone else
will.

2) We could say 1.0.0 is the minimum.

This would have the advantage of setting an easily recognisable
boundary. 1.0.0 has a pretty well defined feature set so we'd have
something solid to work with. The downside would be that we'd now be
requiring that macos developers use macos ports to get a version of
openssl that works properly, users of long term support versions of
linux such as rhel would be in a similar position.

3) We could pick another version as a minimum.

This would have to be based on the versions used by the various long
term supported distributions such as rhel, suse enterprise etc.

4) Your idea here.

Have a better idea? Please describe it.

Cheers

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

Re: [Development] Setting a Minimum Support OpenSSL Version

[Richard Moore]

On 16 April 2013 19:16, Raul Metsma r...@innovaatik.ee wrote:
 We saw weird behaviours when mixing in our application openssl 1.0.0 and 
 using Security.framework/TokenD.
 Using stock openssl resolved this.

Can you provide a bit more detail on this?

Cheers

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