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 pro
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
___
+1
On 21 March 2018 at 12:00, Edward Welbourne wrote:
> Lars Knoll (21 March 2018 12:49)
> > He isn’t an approver yet? I agree, that we should change that :)
>
> My thought entirely !
>
> +1,
>
> Eddy.
> ___
> Development mailing list
> Develop
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
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
Developme
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
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,
>
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 co
Resend from the right address
On 16 October 2017 at 18:38, Richard Moore wrote:
> I need to polish up my code showing how to add in additional openssl
> features. This can be used to extend it's support without bloating
> qtnetwork or qtbase.
>
> On 13 Oct 2017 8:44 am,
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
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
On 8 March 2017 at 10:37, Kai Koehne wrote:
> > -Original Message-
> > From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> > project.org] On Behalf Of Richard Moore
> > Sent: Tuesday, March 07, 2017 10:44 PM
> > To: Lars Knoll
> >
>
>
> 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 voca
On 7 March 2017 at 21:21, Lars Knoll wrote:
>
> > On 7 Mar 2017, at 21:54, Thiago Macieira
> wrote:
> >
> > Em terça-feira, 7 de março de 2017, às 21:37:46 CET, Richard Moore
> escreveu:
> >>> The Qt Company has now very recently made a decision to
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 th
On 3 March 2017 at 11:33, Marc Mutz wrote:
> On Friday 03 March 2017 10:43:56 Richard Moore wrote:
> [...]
> > QSslCipher should be an integer index into a table. The
> > fact that it isn't is a poor workaround for weak API from openssl
>
> Would you mind to expa
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
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 pac
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.
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
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
On 26 July 2016 at 22:33, Henry Skoglund wrote:
> Hi, most likely I've had too much coffee, but has anyone checked if these
> intermittent crashes are due to outside DDOS/some trying to introduce a
> race condition and injecting new code into Qt's codebase?
>
The CI machines aren't internet acc
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.
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 mo
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 exce
+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
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 th
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
Resending from the right address.
-- Forwarded message --
From: Richard Moore
Date: 9 December 2015 at 17:22
Subject: Re: [Development] RFF: nullptr rules
To: "development@qt-project.org"
On 9 December 2015 at 15:14, Marc Mutz wrote:
> - 0 as a nullptr const
Thanks for the quick resolution!
Rich.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
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/devel
On 14 August 2015 at 10:45, Knoll Lars wrote:
> Let’s get that one in as well.
>
Not really a security fix but we'll also want to get the fix to make
Apple's ancient openssl to work with apple's certificate store in once the
patch is ready.
Rich.
_
See http://code.woboq.org/qt5/qtbase/src/network/ssl/qssl.h.html#75
Note that qdoc doesn't like it much.
Rich.
On 12 August 2015 at 13:36, Denis Shienkov wrote:
> Hi All.
>
> Is it possible to use QT_DEPRECATED_SINCE macro for the specific enum
> values? And, is any restrictions related to the
On 10 August 2015 at 10:01, Paul Olav Tvete
wrote:
> I would like to propose a new playground repository for upstreaming the
> QtMir
> project from Canonical:
>
Will the canonical developers be working directly in this repository? If
so do we need to consider how their changes will be reviewed
On 3 August 2015 at 11:55, Heikkinen Jani
wrote:
> Is there something which prevents us to proceed as planned? Is new CI
> system working well enough etc? Is Qt5.git update working ok in dev?
>
>
> CI for Macos is still picking up the wrong openssl (it is using 0.9.8 at
run time). This prevents
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
On 13 March 2015 at 21:08, Denis Shienkov wrote:
> So, nor SSH, nor HTTS does not work for me. What happens? :(
>
You're using the wrong port.
Rich.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/d
On 10 March 2015 at 14:22, Jan Kundrát wrote:
> On Sunday, 22 February 2015 16:27:44 CET, Giuseppe D'Angelo wrote:
> > * RHEL 6 ships 1.0.0, EOL Nov 2020
>
> This is a bit more complex with RHEL because there are many "RHEL 6"s. RHEL
> 6.5 and newer ship with 1.0.1e [1], so they are already cover
On 22 February 2015 at 18:02, Thiago Macieira
wrote:
> > No, there will be no more updates for < 1.0.1 after december. The
> lifespan
> > of 1.0.1 has not yet been set. They seem to be doing the work to make the
> > code more maintainable, then they'll probably have a longer lifespan.
>
> I meant
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/
On 22 February 2015 at 20:08, Sorvig Morten
wrote:
>
> > On 22 Feb 2015, at 18:50, Jeremy Lainé wrote:
> >
> > On 02/22/2015 06:42 PM, Richard Moore wrote:
> >>
> >>
> >> On 22 February 2015 at 17:39, Jeremy Lainé
> wrote:
> >>
&
On 22 February 2015 at 17:50, Jeremy Lainé wrote:
> On 02/22/2015 06:42 PM, Richard Moore wrote:
>
>
>
> On 22 February 2015 at 17:39, Jeremy Lainé wrote:
>
>>
>> Whilst I agree with the goal of dropping support for old / unmaintained
>> OpenSSL versions,
On 22 February 2015 at 17:39, Jeremy Lainé wrote:
> Hi Rich,
>
> On 02/21/2015 06:30 PM, Richard Moore wrote:
> > Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
> > frame:
> >
> > * Complete removal of openssl 0.9.8 support
&g
On 21 February 2015 at 18:38, Thiago Macieira
wrote:
> > I suspect enterprise distros etc. will continue to support 1.0.0 for a
> > while. I'm not sure of the level of adoption of 1.0.1 at the moment, so I
> > was erring on the side of caution. Any feedback on this is welcome.
>
> And with CII su
On 21 February 2015 at 18:38, Konstantin Ritt wrote:
> 2015-02-21 22:05 GMT+04:00 Richard Moore :
>
>>
>> On 21 February 2015 at 17:34, Konstantin Ritt wrote:
>>
>>> 2015-02-21 21:30 GMT+04:00 Richard Moore :
>>>
>>>> Here's an o
On 21 February 2015 at 17:54, Giuseppe D'Angelo wrote:
> On 21 February 2015 at 18:30, Richard Moore wrote:
> > Openssl 0.9.8 will reach EOL in December anyway. In addition to removing
> the
> > support from the sources, I suspect this will involve some changes to
On 21 February 2015 at 17:34, Konstantin Ritt wrote:
> 2015-02-21 21:30 GMT+04:00 Richard Moore :
>
>> Here's an outline of stuff I'd like to see get done in the Qt 5.6 time
>> frame:
>>
>> * Complete removal of openssl 0.9.8 support
>>
>>
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 intr
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/
_
The main one I'm aware of the the securetransport SSL backend. I'm hoping
to spent some time looking at it, but more eyes would help.
https://codereview.qt-project.org/#/c/101485/
Cheers
Rich.
On 29 January 2015 at 10:02, Knoll Lars wrote:
> Hi everybody,
>
> Just a short reminder to you all t
QSslSocketPtr socket2 = newSocket();
this->socket = socket2.data();
socket2->setCaCertificates(QList());
socket2->connectToHostEncrypted(host, 443);
QVERIFY(!socket2->waitForEncrypted());
Grr.
Rich.
On 26 January 2015 at 20:54, Richard Moore wrote:
>
>
>
On 26 January 2015 at 19:28, Marc Mutz wrote:
> I guess that's the reason why no integration succeeds in qtbase atm (always
> some ssl test error)?
>
> If so, it might be a good idea to suspend qtbase integration tasks until
> it's
> fixed, unless people like to have it running as a compilation o
On 28 December 2014 at 13:26, Thiago Macieira
wrote:
> On Sunday 28 December 2014 13:11:13 Richard Moore wrote:
> > At the moment there are still a lot of SSL accelerators out there with
> > these problems. We can probably stop worrying in around a year once all
> the
>
On 27 December 2014 at 12:48, Thiago Macieira
wrote:
> On Saturday 27 December 2014 10:52:41 Richard Moore wrote:
> > Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
> > then if you're connecting to old servers the TLS extensions will lead the
&g
On 27 December 2014 at 11:44, Mikkel Krautz wrote:
> On Sat, Dec 27, 2014 at 11:52 AM, Richard Moore wrote:
> > On 26 December 2014 at 21:12, Thiago Macieira >
> > wrote:
> >
> > Hmm, if you set TLS 1.0 you really need to only negotiate TLS 1.0. If not
> &
On 26 December 2014 at 21:12, Thiago Macieira
wrote:
>
> I don't think we need fine-grained detection, but we do need something
> better
> than what we have right now.
>
> My suggestion is to set a level. For example, if you set to TlsV10, then
> you
> get TLS v1.0 and anything newer, existing to
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
>
>
__
On 10 September 2014 21:15, Thiago Macieira
wrote:
> On Tuesday 09 September 2014 18:24:58 Валерий Котов wrote:
> > I realize that we had this discussion before. But I have to ask. =)
> > Does not it make sense to add method and type in Operations enum for
> > options in case we need some special
On 4 September 2014 10:29, Allan Sandfeld Jensen wrote:
> On Thursday 04 September 2014, Richard Moore wrote:
> > On 3 September 2014 20:25, Thiago Macieira
> >
> > wrote:
> > > > > How is it represented in HTML5?
> > > > > Just do it the s
On 3 September 2014 20:25, Thiago Macieira
wrote:
> > > How is it represented in HTML5?
> > > Just do it the same way.
> >
> > I'm a little unsure that I understood. Could you please clarify what did
> > you mean by "represented in HTML5"?
>
> XMLHttpRequests have existed in JavaScript and HTML5
On 27 August 2014 14:55, Oswald Buddenhagen
wrote:
> On Fri, Aug 22, 2014 at 07:21:38AM +, Knoll Lars wrote:of course lgpl2
> still makes sense for add-ons hosted outside qt-project,
> and ones where the author explicitly doesn't want digia to make money
> from selling this module (though in
-- Forwarded message --
From: Richard Moore
Date: 15 July 2014 22:55
Subject: Re: [Development] Nominating Milian Wolff as approver
To: Gladhorn Frederik
He isn't already? +1
Rich.
On 15 July 2014 21:08, Gladhorn Frederik
wrote:
> Hi all,
>
> it's my p
The 2.0.1 release of libressl has addressed the problem and it now builds.
Rich.
On 13 July 2014 11:14, Richard Moore wrote:
> Just to save anyone else trying, I had a quick go of building Qt against
> libressl and it isn't currently capable of building Qt. The problems are
>
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 mai
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
On 23 June 2014 18:21, Stottlemyer, Brett (B.S.) wrote:
> As for Replicant, yes we will need have a playground established for that.
>
> According to
> http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt, I need
> approval from a Qt Maintainer before I can submit a new Gerrit project.
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.
___
On 2 June 2014 13:12, Keith Gardner wrote:
> On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
> wrote:
>
>>
>> I suggest a name that is more centric towards the _function_ of the class,
>> comparison of different software versions.
>>
>
> QVersionInformation was also proposed as a name in the code
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
On 11 May 2014 02:16, Keith Gardner wrote:
>
>1. Usually more condensed than the pre-release.
>2. Some projects experience multiple "releases" with the same version
>of software (1.0.0-2).
>3. Libjpeg and OpenSSL use a single letter to represent a level of
>security for some s
On 3 May 2014 22:38, Thiago Macieira wrote:
> Em sáb 03 maio 2014, às 22:23:30, Richard Moore escreveu:
> > - A small but significant number of apps use client certificates.
> >
> > - A small but significant number of apps use server SSL sockets.
> >
> > - Very
On 3 May 2014 22:42, Thiago Macieira wrote:
> Em sáb 03 maio 2014, às 22:23:30, Richard Moore escreveu:
> > Simplifying the Cipher API
> > ==
> >
> > Currently, the QSslCipher API is pretty large. It's not simply the
> > code in the
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
On 3 May 2014 11:28, Kurt Pattyn wrote:
> Hi,
>
> I would like to know if there are any guidelines about using qDebug and
> friends in Qt source code?
> Recently I had to remove qWarning statements from a submit (for very
> plausible reasons), but a quick search through qtbase revealed a lot of
>
On 29 April 2014 12:13, Sorvig Morten wrote:
> >> What would the best course of action be to add support for secure
> websockets
> >> on iOS?
> >
> > Probably to add a new QSslSocket backend that uses the Apple API.
>
> QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make
> sure
On 27 April 2014 22:31, Mark Gaiser wrote:
> Actually, you can..
> http://css-tricks.com/a-couple-of-use-cases-for-calc/
>
> And even Internet Explorer has support for it:
> http://caniuse.com/#feat=calc
>
>
It's a variant of the expression() facility that IE has offered to CSS
since IE6. It's ex
On 25 April 2014 11:51, Alberto Mardegan wrote:
> For instance, I would like to have a GeoPoint type with "latitude" and
> "longitude" properties; if I exposed it as a QVariantMap, I wouldn't be
> able to prevent the QML code from doing stuff like:
> p.latitude = 60
> p.longitde = 10 // note the t
On 22 April 2014 16:20, Martin Koller wrote:
> Where do I find the sources for Qt Designer ?
> Or is there no longer a stand-alone designer application in Qt5 as was in
> Qt4 ?
>
https://qt.gitorious.org/qt/qttools/source/e7b791c8bb5e64a4c786bf370b10366815af704f:src/designer
Cheers
Rich.
_
http://www.viva64.com/en/b/0251/
I've fixed a few of the copy-paste errors, but I've not gone through the
whole list:
https://codereview.qt-project.org/#change,83763
https://codereview.qt-project.org/#change,83764
https://codereview.qt-project.org/#change,83765
https://codereview.qt-project.org/#
+1
On 15 April 2014 18:13, Thiago Macieira wrote:
> Hello
>
> I'd like to nominate Jake Petroules as approver. He's been very active in
> the
> Mac port in the recent months, helping out with issues like adding support
> for
> the CoreFoundation types in QtCore, among other tasks. He's located
On 9 March 2014 20:13, Kurt Pattyn wrote:
>
> On 09 Mar 2014, at 21:02, Giuseppe D'Angelo wrote:
>
> > On 9 March 2014 15:10, Kurt Pattyn wrote:
> >> Also, the connection between the authenticationRequired signal and the
> slot
> >> must be a direct connection.
> >
> > IIRC SSL sockets had the
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. L
On 12 February 2014 14:44, Konrad Rosenbaum wrote:
> On Wednesday, Wednesday 12 February 2014 at 08:01, Kurt Pattyn wrote:
>> On 11 Feb 2014, at 19:14, Thiago Macieira wrote:
>> > Em ter 11 fev 2014, às 16:26:44, Tony Van Eerd escreveu:
>> >> http://channel9.msdn.com/Events/GoingNative/2013/rand-
On 30 January 2014 14:22, Koehne Kai wrote:
>
>
>> -Original Message-
>> From: development-bounces+kai.koehne=digia@qt-project.org
>> [...]
>> Again, only 3rd party untrusted content matters here and for that you need a
>> sandbox.
>
> I'm not entirely sure '3rd party untrusted content
On 30 January 2014 12:26, Konrad Rosenbaum wrote:
> On Wednesday, Wednesday 29 January 2014 at 21:25, Richard Moore wrote:
>
>> Sorry but most of this is irrelevant to Qt. Qt applications and QML
>
>> applications are not like Javascript in a browser - they're al
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).
C
On 26 January 2014 19:23, Kurt Pattyn wrote:
>> 2. When sending data from client to server (not the other way)
>> The client generates a 32-bit random number.
>> This random number is stored in plain text in the header of each frame.
>> The data is XOR-ed with that 32-bit random number.
>>
>> The
>> 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 differenc
h.
>
> Cheers,
>
> Kurt
>
>> On 17 Jan 2014, at 12:25, Richard Moore wrote:
>>
>>> On 17 January 2014 07:54, Knoll Lars wrote:
>>>
>>> From a feature point of view it would fit best into Qt Network. But it's a
>>> sizeable piece of code
Resend from the right email address.
-- Forwarded message --
From: Richard Moore
Date: 17 January 2014 11:25
Subject: Re: [Development] Qt 5.3 Feature freeze is coming quite soon...
To: Knoll Lars
Cc: Steve Gold , Kurt Pattyn
, "development@qt-project.org"
, Heik
On 2 January 2014 18:33, Jiergir Ogoerg wrote:
> It's not for documentation purposes (not for those using Qt to create
> apps), but for those working with the Qt code.
> Currently, if you're coding a method you put it virtually anywhere in the
> file.
> If you have 30 methods they're put alphabet
On 30 December 2013 16:07, Mandeep Sandhu wrote:
So I guess having body in the 3xx response will not be all that unusual.
>>>
>>> It will be.
>>
>> Actually, it's extremely common - here's a default apache 301 for example:
[snip]
> I guess the body is provided for clients who can't or intent
On 30 December 2013 11:25, Thiago Macieira wrote:
> On segunda-feira, 30 de dezembro de 2013 11:23:29, Mandeep Sandhu wrote:
>> > Maybe rare for URL shorteners. Internal redirects inside a web site or
>> > group of sites are a different matter: call me an old-grumpy-Mosaic-user
>> > if you like, b
On 26 December 2013 17:10, Mandeep Sandhu wrote:
> On Thu, Dec 26, 2013 at 8:12 PM, Richard Moore wrote:
>> On 26 December 2013 13:11, Thiago Macieira wrote:
>>> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
>>>> We could emit download
On 26 December 2013 13:11, Thiago Macieira wrote:
> On quinta-feira, 26 de dezembro de 2013 18:15:56, Mandeep Sandhu wrote:
>> We could emit download progress for each intermediate request, but
>> won't that look strange to a user as the bytes received & _possibly_
>> bytes total values will keep
On 26 December 2013 12:45, Mandeep Sandhu wrote:
>>> Your thoughts?
>>
>> The download progress signal will have to be emitted for the
>> intermediate requests. Things like operation() and url() are stored in
>> the request object which can't be changed by the QNAM at all. If
>> people want all th
On 25 December 2013 07:54, Mandeep Sandhu wrote:
>>>
>>> 3. QNetworkReply stores both, the original as well as the final url.
>>
>> What about the intermediate ones in a chain of redirects?
>>
>
> Another question that springs to mind is what should the QNetworkReply
> object returned to the user
On 24 December 2013 07:57, Mandeep Sandhu wrote:
> Hi All,
>
> Few days back I stumbled upon this task:
> https://bugreports.qt-project.org/browse/QTBUG-8232
>
> "QNetworkAccessManager should support redirection"
>
> I think this is a useful feature that can be added to QNAM as it makes
> the life
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
On 15 November 2013 19:51, Alan Alpert <4163654...@gmail.com> wrote:
> On Fri, Nov 15, 2013 at 2:00 AM, Kevin Krammer wrote:
>> On Thursday, 2013-11-14, 21:20:25, Topi Mäenpää wrote:
>>
>> I also wouldn't consider widgets to be deprecated, at least not yet. And
>> nicely use QML with widgets as th
1 - 100 of 175 matches
Mail list logo
