[Development] Qt in Google's OSS-Fuzz
Hello, after Google announced their continuous fuzzing approach some days ago (see [1]), I tried to make Qt work with it and the fuzzing testcases I have written the last weeks ([2]). If people agree, we could try going forward with putting Qt onto OSS-Fuzz as well. I am almost there with setting it up ([3]), and once this is done I don't expect a lot of maintenance. The fuzzing test cases ([2]) could be hosted as a Qt playground project instead of github if desired. As a side note, this platform already contains libraries that Qt uses, e.g. OpenSSL, zlib, harfbuzz, ICU and others. Regards, Peter [1] https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html [2] https://github.com/peter-ha/qt-fuzzing [3] https://github.com/peter-ha/oss-fuzz/tree/qt -- Peter Hartmann // Titurelstrasse 2 // 89125 Munich // Germany pe...@hartmann.tk www.peter.hartmann.tk ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt in Google's OSS-Fuzz
On 06.12.2016 12:45, Giuseppe D'Angelo wrote: I'm all for it, and I think we should fuzz all sorts of "parsers" inside Qt (HTTP, JSON, image formats, CSS, HTML, ...). good idea, as I said we could host the tests as a playground project or so and let people add more test cases... To address Milian's other comments, building Qt and checking out the right version etc. would be hosted inside Google's repos (see e.g. the build script for curl: https://github.com/google/oss-fuzz/blob/master/projects/curl/build.sh); they also provide tools and documentation on how to run this locally. We could make the security mailing list the direct email contact in case issues are found; I just don't know how much noise this would produce. Anyhow I think we could find a solution that works for everybody... Peter -- Peter Hartmann // Titurelstrasse 2 // 89125 Munich // Germany pe...@hartmann.tk www.peter.hartmann.tk ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Submitting Qt to oss-fuzz
Hello, sounds like a good initiative, I was asking about the same thing 2 years ago ([1]) but then somehow didn't follow up on this. Back then I also wrote some simple fuzzing test cases ([2]) that found some crashes and memory corruptions ([3]), I would be happy to contribute them if they are deemed useful. Regards, Peter [1] http://lists.qt-project.org/pipermail/development/2016-December/028016.html [2] https://github.com/peter-ha/qt-fuzzing [3] https://www.peter.hartmann.tk/single-post/2016/11/29/Fuzzing-Qt-with-libFuzzer On 31.08.2018 11:24, Robert Löhning wrote: > Hi everybody, > > yes I did. So far I have been working on getting Qt into a better > shape for fuzzing at all, resulting in [1]. > > This prepares a Qt build for being fuzz tested with clang's libFuzzer, > the tool that Google also uses in oss-fuzz. The fuzzer I used for > testing my setup already found a crash. > > What I have so far: > - fuzzing Qt with libFuzzer locally, using [1] > - AFAICS collected all the needed "OK"s to enter Qt [2] > > What I don't have so far: > - create the pull request for [2], wanted to do this now-ish > - Everything that comes after registering the project like: > - setting up build/run on Google's servers > - finding out what kind of dashboard I'll get there > > I would appreciate if I might use the scripts you posted, Albert, or > if we could work on this together. > > Cheers, > Robert > > [1] https://codereview.qt-project.org/236937/ > [2] https://github.com/google/oss-fuzz/compare/master...rlohning:master > > Am 30.08.2018 um 21:27 schrieb Lars Knoll: >> Hi Albert, >> >> Nice! Robert has been working on exactly the same thing lately. I >> think it would be good if you guys coordinated the effort :) >> >> It would be ideal, if we could somehow get those mails forwarded to >> the security mailing list. I wonder whether we could do that with a >> special mail account that forwards to the security mailing list. >> >> Cheers, >> Lars >> >>> On 30 Aug 2018, at 20:42, Albert Astals Cid via Development >>> wrote: >>> >>> oss-fuzz is an online fuzzing service run by Google. >>> >>> They test daily the code base and run fuzzying over it, maintaining >>> a list of open and closed bugs. >>> >>> As example you can see one of the poppler issues i fixed at >>> https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=9382 >>> >>> Everything is done automatically by a bot, except my "This is fixed >>> by" comment, but that's just there for historical reasons, it's not >>> really needed. >>> >>> Found bugs are sent to a list of trusted address and kept private >>> for 90 days, then if not fixed then they become public. >>> >>> Fixed bugs become public 30 days after being fixed. >>> >>> I have made a qimage fuzzer that uses libpng test files as seed corpus. >>> >>> You can find it at https://github.com/albert-astals-cid-kdab/oss-fuzz >>> >>> Adding support for Qt is "relatively simple" see >>> https://github.com/albert-astals-cid-kdab/oss-fuzz/commit/2df60c7af6619b8a6a44b1cd679bf356e6e6ed3f >>> >>> >>> I made a local test run of the undefined sanitizer and it found >>> https://paste.kde.org/prkox41mx >>> in a few seconds, so "it works" >>> >>> If you want to test it locally you can do >>> python infra/helper.py build_fuzzers --sanitizer undefined qt >>> python infra/helper.py run_fuzzer qt qimage_fuzzer >>> for the undefined sanitizer and >>> python infra/helper.py build_fuzzers --sanitizer address qt >>> python infra/helper.py run_fuzzer qt qimage_fuzzer >>> >>> Unfortunately I have not been able to compile with the memory >>> sanitizer enabled yet. >>> >>> The most important thing before submitting this upstream is changing >>> the list of trusted addresses the private bugs get sent to. >>> >>> To have something written i've used my email address but i guess at >>> least i should add eirik.aavitsl...@qt.io (listed as QImage >>> maintainer) there too? Anyone else? >>> >>> I am not sure how the email address thing works, but i think they >>> need to be "google account" activated, whatever that means, so we >>> can't use secur...@qt-project.org. On poppler i'm using my >>> @gmail.com address and not my @kde.org address since it was just >>> easier.
Re: [Development] Submitting Qt to oss-fuzz
Hello Robert, On 04.09.2018 14:03, Robert Löhning wrote: > I saw your post and it helped me get started. Thanks for that! cool, thanks for the feedback! > > By the way: In step 1 you use > -fsanitize-coverage=edge > whereas I followed LLVM's example [1] and used > -fsanitize-coverage=trace-pc-guard > > Unfortunately the documentation seems to be a bit scarce. Could you > please tell me briefly about the advantages of either one? > > I guess I should include "edge" to [2], shouldn't I? Instead of > hacking the mkspec you could then just use > /configure -sanitize address -coverage edge The "-fsanitize-coverage=edge" just comes from an older clang version when there was no trace-pc-guard. Nowadays "trace-pc-guard" without other args implies "edge", so the latter can be ignored when configuring with address sanitizer. IIUC edge just provided information on whether a piece of code was executed or not, while trace-pc-guard provides a callback which allows for more fine-grained coverage information; the callback itself is then implemented in libFuzzer. What might be interesting to look at is "-fsanitize-coverage=trace-cmp" though... Regards, Peter -- Peter Hartmann // Titurelstrasse 2 // 89125 Munich // Germany pe...@hartmann.tk www.peter.hartmann.tk ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Submitting Qt to oss-fuzz
Hello Robert, On 05.09.2018 13:08, Robert Löhning wrote: > if (x == 0) > foo() > else > bar() > > Then all values of x will be considered different. For fuzzing, though, > only the two cases x == 0 and x != 0 will matter. > > Do I miss something here? yes I think it would consider all comparisons different; from what I understand it gives the fuzzer a better understanding of which part of the input needs to be altered to follow a different code path. Anyhow the libFuzzer documentation at https://llvm.org/docs/LibFuzzer.html says: "This may slow down the fuzzing but is very likely to improve the results." Regards, Peter -- Peter Hartmann // Titurelstrasse 2 // 89125 Munich // Germany pe...@hartmann.tk www.peter.hartmann.tk ___ 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
On 12/31/2013 06:35 AM, Mandeep Sandhu wrote: > Okay. I think Richard also suggested the same approach, i.e as long as > we are being redirected, we don't emit the downloadProgress (and other > signals indicating there is data available) and do it only once we > arrive at the final url (though we continue to read the full response > of each redirect). So the final signals will reflect the data as if > the request was made directly to that url. Is that your understanding > too? Sounds good to me as well; while technically a site often sends a body with a redirect, in practice all the information needed is stored in the "Location:" header. So we could just discard the body for redirecting replies in the "follow automatic redirects" case. If an app does want to use the body, it could still handle redirects itself... Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] new Jira Network assignees
Hello, in case somebody is interested: Rich and me just agreed on distributing the default assignees for the Jira Network components: Rich Network Rich Network: Authentication PeterNetwork: BearerManagement PeterNetwork: Cache Rich Network: Cookies Rich Network: DNS (unassigned) Network: FTP PeterNetwork: HTTP (new component) PeterNetwork: SPDY (new component) PeterNetwork: Proxies PeterNetwork: Sockets Rich Network: SSL Thiago Network: URL handling Some comments: * In practice it is not clear beforehand who does what, and distributing the components was somewhat arbitrary * FTP is considered "done" (right?), so there is no default assignee * SPDY component is new and the code will hopefully be ready for 5.3. I thought it might be a good idea to add it now while we are at it... * Thiago is the default assignee for URL bugs, as QUrl is part of QtCore (I guess it was like this already) Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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...
On 01/17/2014 08:54 AM, Knoll Lars wrote: > From a feature point of view it would fit best into Qt Network. But > it's a sizeable piece of code added to Qt Network. Do you have any > numbers on how this changes the size of Qt Network? > > Peter and Rich, and comments from your side? Size-wise I think it is ok; we could add QT_NO_WEBSOCKETS defines or so if somebody wants to exclude it. Also the API looks clean and very similar to our current socket APIs; IIRC Shane did some review already, I did not look into it closely. One thing I have been wondering about wrt web sockets is: Where are they actually used? I am not saying they are not, but I have never come across a big site (Facebook, Twitter etc.) that offered clients to use it. The only thing I have found is this rather outdated discussion, which mentions a few sites: http://www.quora.com/Which-sites-are-using-websockets-right-now Again, I am not saying we don't want it; I just want to gain some more understanding on whether we want it directly in QtNetwork... Another thing: Kurt, would you be willing to maintain this part of the code? I probably will not be looking into it too much until it benefits my employer (i.e. if some BlackBerry app is using it). Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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...
On 01/17/2014 08:49 PM, Kurt Pattyn wrote: > So, based on the feedback, can everybody agree on QtWebSockets being an > add-on? > It keeps the core as is, and provides an opt-in for applications that need it. +1, this sounds like the best solution to me... Peter > > Cheers, > > Kurt > >> On 17 Jan 2014, at 12:25, Richard Moore wrote: >> >>> On 17 January 2014 07:54, Knoll Lars wrote: >>> >>> From a feature point of view it would fit best into Qt Network. But it's a >>> sizeable piece of code added to Qt Network. Do you have any numbers on how >>> this changes the size of Qt Network? >>> >>> Peter and Rich, and comments from your side? >> >> Given that the websocket code contains both C++ networking stuff and >> also QML it cannot all go into qt network as this would introduce a >> circular dependency on the qtdeclarative module. This would mean >> splitting it into two one part in qt network and another in qt >> declarative which I think would be a bit confusing for users. >> >> On the other hand as an addon module the dependency problem is gone >> and it can be available as a single self-contained module (with >> unified documentation) which I suspect would be easier on those using >> the module. I don't think adding QT += websockets to the pro file >> would be a barrier for adoption. >> >> Given the above (and ignoring the issue of code-size etc.) my initial >> feeling is that an addon module is probably a better choice for users >> of the module. >> >> Cheers >> >> Rich. - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Need suggestion for a new API
On 01/31/2014 01:47 PM, Mandeep Sandhu wrote: > (...) > The QNAM setting can be a simple bool which defaults to 'false' if not > explicitly set by the user. However, the request level setting needs 3 > states - true (follow redirects), false (don't follow) and unset (use > global setting). How about enabling the setting on a per-request basis first? In that case, the normal way would be to add a new value to the QNetworkRequest::Attribute enum, and a boolean would be enough I think. In general I also think it would be a good thing to have a way of setting such things globally in QNetworkAccessManager, but that would require some more API in that class then... So maybe we could have 2 commits: One that enables redirect settings on a request first, and then introduce global QNetworkAccessManager settings (which might be some more work)... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again?
Update: There is still one problem that prevents us from deploying the new network test server image. The problem only shows within the Digia network; I cannot reproduce it locally. This makes it somewhat tedious to debug, if somebody from Digia has more insights or wants to help debugging, I would be happy to hear. So far I have sent patches to Tony, who applied them for me and pasted me the results, which makes turnaround time quite long. What I think the problem is: We get 2 Socks messages in 1 TCP packet, so the read notifier only fires once, then we never parse the 2nd Socks message. Peter On 02/06/2014 01:54 PM, Sarajärvi Tony wrote: > Hi > > We've discovered (just lately) that in some cases incoming TCP packages are > bundled together. Somewhere along the line in our network code the first TCP > packet is drawn from buffers, but the remainders are left there. It's a > random thing, which we can reproduce in our test rig where we develop the new > network test server (that's supposed to replace this old one as soon as we > get it 100% working). Peter is working on the problem it and hopefully we'll > get a patch for it soon. > > Reagards, > -Tony > >> -Original Message- >> From: development-bounces+tony.sarajarvi=digia@qt-project.org >> [mailto:development-bounces+tony.sarajarvi=digia@qt-project.org] On >> Behalf Of BogDan >> Sent: 6. helmikuuta 2014 14:26 >> To: Mandeep Sandhu; Thiago Macieira >> Cc: development@qt-project.org >> Subject: Re: [Development] CI broken again? >> >> Hi, >> >>> >>> In your case, the QDnsLookup failure is caused by your code. It happened >> 100% of the time that the QDnsLookup test was executed and it did not happen >> when your change wasn't present. >>> >>> >>> It can't be related to my change as the same tests pass 100% of the time on >> my local setup (Ubuntu 13.10) and moreover my changes do not kick-in if the >> name server is not specified (which is the case with all the failing test >> cases). >>> >>> >>> The latest test failures seemed to be due to timeout rather than anything >> else. The 'waitForDone()' function is exiting with a failure due to DNS >> lookup >> timeout. The current timeout is set to 10 secs. This is quite large, but >> still, >> could there be a network issue with the CI setup? >>> >>> >> >>Ok, maybe his patch has some problems, but I'm pretty sure that my patch >> was staged without his patch a few times and it still failed :( . A little >> help >> from CI folks will be very appreciated! >> >>Is a little bit frustrating to fix a problem in a few minutes and wait a >> few days >> to integrate it :). >> >> Cheers, >> BogDan. >> >> ___ >> 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] CI broken again?
On 02/19/2014 05:22 PM, Thiago Macieira wrote: > Em qua 19 fev 2014, às 17:20:13, Peter Hartmann escreveu: >> What I think the problem is: We get 2 Socks messages in 1 TCP packet, so >> the read notifier only fires once, then we never parse the 2nd Socks >> message. > > What 2 SOCKS messages are those and which command did we send? Unfortunately the codepaste from the Digia test has expired; IIRC they were the 2 responses to our Connect Command: 1. Results(V5): Succeeded, Address Type, Remote Address, Port 2. Command: Connect, Remote Address, Remote Port So I think we need to make the our socket engine parse the 2nd message as well, even without an explicit readyReady(). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
Hello,
it might be the socket is bind()ing to a local address when it does not
need to; would you be able to file a bug report with a program to
reproduce the problem?
Thanks,
Peter
On 02/26/2014 09:28 AM, Mauro Brenna wrote:
> Hello Jan,
>
> Thanks for the suggestion.
>
> The answer is YES they are behaving quite differently:
>
> Here the output while in the for loop:
>
> QT4.8.5
>
>
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
> sendto(7, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET,
> sin_port=htons(45454), sin_addr=inet_addr("255.255.255.255")}, 16) = 19
>
>
> QT 5.1.1
>
>
> sendto(6, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET6,
> sin6_port=htons(45454), inet_pton(AF_INET6, ":::255.255.255.255",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 19
> socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
> ioctl(7, SIOCGIFINDEX, {ifr_name="", ???}) = -1 ENODEV (No such device)
> close(7)= 0
> sendto(6, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET6,
> sin6_port=htons(45454), inet_pton(AF_INET6, ":::255.255.255.255",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 19
> socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
> ioctl(7, SIOCGIFINDEX, {ifr_name="", ???}) = -1 ENODEV (No such device)
> close(7)= 0
> sendto(6, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET6,
> sin6_port=htons(45454), inet_pton(AF_INET6, ":::255.255.255.255",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 19
> socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
> ioctl(7, SIOCGIFINDEX, {ifr_name="", ???}) = -1 ENODEV (No such device)
> close(7)= 0
> sendto(6, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET6,
> sin6_port=htons(45454), inet_pton(AF_INET6, ":::255.255.255.255",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 19
> socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
> ioctl(7, SIOCGIFINDEX, {ifr_name="", ???}) = -1 ENODEV (No such device)
> close(7)= 0
> sendto(6, "Broadcast message 0", 19, MSG_NOSIGNAL, {sa_family=AF_INET6,
> sin6_port=htons(45454), inet_pton(AF_INET6, ":::255.255.255.255",
> &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 28) = 19
> socket(PF_FILE, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 7
> ioctl(7, SIOCGIFINDEX, {ifr_name="", ???}) = -1 ENODEV (No such device)
> close(7)= 0
>
> What can I do to have the same behaviour as QT 4.8.5. It sounds like a
> QT5 .1.1 is trying to set a connection or something like that.
>
> Kind regards,
>
> Mauro
>
>
>
>
>
>
>
> On 25 February 2014 18:46, Jan Kundrát > wrote:
>
> On Tuesday, 25 February 2014 16:56:53 CEST, Mauro Brenna wrote:
> > I looked a bit in the qt code and saw a bind() inside the QT5
> > writeDatagram method, which I do not immediately understand but I
> do not
> > know if might cause the issue.
>
> Is there any difference in `strace` when you instrument the Qt4 and Qt5
> versions of the test?
>
> Cheers,
> Jan
>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists
Re: [Development] Performance of QUdpSocket writeDatagram between Qt4 and Qt5 in different GNU/Linux platforms
On 02/26/2014 10:56 AM, Mauro Brenna wrote: > no I haven`t report it in a bug tracker yet. I still do not know if it > is just an issue related to my specific platform. If you had an example program to reproduce the problem, I could check on my side whether the problem can be reproduced. Maybe the bug tracker (https://bugreports.qt-project.org/) is the right way to discuss this further... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] FTP in Qt5
On 03/08/2014 09:36 PM, Thiago Macieira wrote: >> If someone, including the requesting party themselves, does such work, I’m >> >sure there are reviewers / approvers ready to do the reviewing. > Oh, sure. If someone supplied the rewrite, I'm sure we'd be happy to take it > in. We might even help out a little. I am not planning to do any work on FTP either as of now, but if somebody wants to implement something there, feel free to add me as a reviewer... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Spurious downloadProgress signal with incorrect bytesTotal when loading from cache
Hello, On 04/11/2014 11:08 AM, Mandeep Sandhu wrote: > Shouldn't these be having valid size values or is this expected > behaviour for cached content? > > I guess the 1st signal (with incorrect size) being emitted is still a bug. I think if the response comes from the cache the response always reported 0 bytes downloaded; but feel free to create a bug report so we can discuss, as I also think this is not quite intuitive... Thanks, Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.3 change files
On 04/17/2014 01:38 PM, Heikkinen Jani wrote: > It seem some change files are still missing ☹ It would be good to have > at least initial versions before RC… > > All maintainers: If your component doesn’t have 5.3 changes file yet, > please add it as soon as possible! I was under the impression that the changes file is generated from the [ChangeLog] entries in the git commit messages; or is this not the case? Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.3 header diff: QtNetwork
On 04/22/2014 11:57 PM, Sune Vuorela wrote: > On 2014-04-22, Thiago Macieira wrote: >> --- a/src/network/ssl/qsslconfiguration.h >> +++ b/src/network/ssl/qsslconfiguration.h >> @@ -131,6 +132,21 @@ public: >> +static const char NextProtocolSpdy3_0[]; >> +static const char NextProtocolHttp1_1[]; > > These static const char[] kind of triggers my 'something looks wrong and > not like Qt is supposed to look like'-feeling. I haven't investigated > what they are for or how they are set and used. It just looks wrong to > me. The static const char[]s are what we came up with to support both predefined values as well as user-defined values for negotiating the Next Protocol in the SSL handshake, see https://codereview.qt-project.org/#change,64081,patchset=5 and the following patch sets for the discussion... Peter > > /Sune > > ___ > 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] No SSL on iOS ?
On 04/29/2014 06:36 PM, Jeremy Lainé wrote: > OK I have moved my proof of concept code here: > > https://github.com/jlaine/qsslsocketios > (...) > I'll start looking how hard it would be to actually integrate this into > qtbase. Yeah, nice work! I think it would be a good thing to get this into qtbase (should you be willing to contribute this of course); providing only a subset of the QSsl* functionality sounds perfectly fine to me... Peter ___ 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
Hello,
TL;DR: I think we can accept new backends if they support some minmal
client-side API, i.e. they succeed connecting when there are no errors
and fail if something goes wrong.
The big problem IMO is how to advertise to the developer what parts of
the API are supported and what not.
Some inline comments:
On 05/03/2014 11:23 PM, Richard Moore wrote:
> (...)
> - Very few applications use custom trust stores.
I would actually hope that this number increases for security reasons
("certificate pinning"), but most servers do not provide more
information there currently...
> (...)
> 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.
I wonder whether the use case is that important; it would be beneficial
to have a way to display a certificate to a user, but apart from
browsers I usually don't see many apps using this feature (i.e. most
apps just correctly abort and display "SSL error", and some just proceed
anyway, which is bad security-wise).
>
> 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.
Yes it sounds like a good idea to have something simpler for developers,
as probably nobody knows whether "ECDHE-ECDSA-AES256-GCM-SHA384" is
secure or not.
But yeah I think this is a separate discussion, as long as new SSL
backends have secure defaults.
> Proposed Capabilities
> =
>
> * SSL Client
>
> A backend offering this capability must offer the basic client-side
> QSslSocket API.
yes, so it should succeed connecting if everything is fine, and must
fail if something is wrong (e.g. untrusted certificate).
The problem is e.g. when somebody wants to trust only a specific
certificate or so and that part of the API is not supported.
I think all we can do here is to try to document this as good as
possible and issue run-time warnings for not supported methods. Also the
categories suggested below would help...
Peter
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modules in qtbase (was: Re: new "debugsupport" module and API)
On 05/13/2014 12:19 PM, Oswald Buddenhagen wrote: > what's become of the new network test server, anyway? IIRC there is one test failure showing on the new image, but not on the old one (see my mail some months ago: https://www.mail-archive.com/development@qt-project.org/msg14730.html). Once that is fixed, we can try to deploy the new image and see whether it is more stable. But since I cannot reproduce the problem locally, it is hard to fix the issue from outside the Digia intranet; if there was a way for me to access that environment looking into the issue would be more promising... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new network tests
On 06/13/2014 05:28 PM, Thiago Macieira wrote: > I'm separating out the MiniHttpServer into a separate header. Mandeep, maybe it would be enough to use the mini HTTP server in your case for testing all sorts of redirects? If not and you would rather use a full Apache, you would have to set up the network test server locally (see e.g. https://qt.gitorious.org/qtqa/sysadmin/source/57f4907999d8348ee578a3c99abece18efcc393d:README.network_test_server.txt) and either re-use some of the redirection URLs or add some more use cases if you want... Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Network Maintainership Changes
+1 for Timur I am hereby officially stepping down as co-maintainer as well; I was in fact not working any more on QtNetwork for quite some time already, because my day job does not really allow for it... Feel free to ping me on IRC or add me to a code review and I might get back to you though. Peter On 06.09.2016 21:05, Richard Moore wrote: 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for the new QUrl
On 10/25/2011 11:59 AM, ext Thiago Macieira wrote:
> I can't post the code just yet, but I can post the new API.
>
> Questions:
> - I un-deprecated fromEncoded and toEncoded, as they're used everywhere.
> Should I do the same for fromPercentEncoding and toPercentEncoding? They
> convert from QString to QByteArray and vice-versa, while
> QByteArray::fromPercentEncoding operates only on QByteArray.
I would assume they are in widespread use as well; In my opinion you
could well keep those methods, I would expect such a method in QUrl
rather than in QByteArray.
>
> - QUrl::url() returns a QString. It should have a "to" prefix, since it
> returns a temporary. It's the exact same function as toString(). Should it be
> kept?
If it does exactly the same as toString(), why have it at all? Is it to
have an equivalent to scheme(), host() etc.?
>
> - QUrlQuery does not keep the order of the items (it's kept in a hash). Is
> the order important?
I would prefer if the order was kept; e.g. for using OAuth, the
parameters need to be sorted in alphabetical order and then that string
needs to be hashed; changing the order in that case would also change
the hash value and would result in an error when using OAuth.
So I think there are use cases where parameter ordering is important.
Peter
>
> Observations:
> - unlike what I had proposed before, I kept the StrictMode parsing (or will
> have kept). However, unlike Qt 4, the actual parser is tolerant, with
> StrictMode implemented as a checker before the actual parser. This should
> improve in performance because 99% of the users use TolerantMode.
>
> - errorString is much more limited than in Qt 4 because I was only willing
> to
> dedicate 4 bytes for the error (one error code and one QChar). I feel that if
> you need a *real* URL validator, with very detailed explanations, you should
> use a dedicated class, not a generic URL container.
>
> - QString-based methods are rehabilitated, including the constructor and
> toString(). The constructor and copy operator from QString are still
> "disablable" with an #ifdef so you can spot unnecessary parsing. The
> QByteArray based methods are deprecated, except for fromEncoded / toEncoded.
>
> - talking about parsing: it's NOT lazy anymore. It's done at the moment you
> set the URL. Why? Because the one in Qt 4 was NOT THREAD-SAFE. Any use of
> const_cast(this) in a non-detached class is just plain wrong.
>
> - QUrl now operates *only* in encoded mode, but it does partially decode
> wherever possible. The default mode (PrettyDecoded) means most components will
> actually appear decoded, unless the component contains a character that should
> appear encoded in URL or cannot be represented at all in QString (such as a
> lone %80).
>
> - IP addresses are actually parsed and fixed appropriately (see the blog)
>
> - QUrl lowercases the scheme, so you no longer have to write:
> if (url.scheme().compare(QLatin1String("http"), Qt::CaseInsensitive) ==
> 0)
> or the much worse:
> if (url.scheme().toLower() == QLatin1String("http"))
>
>
> class Q_CORE_EXPORT QUrl
> {
> public:
> enum ParsingMode {
> TolerantMode,
> StrictMode
> };
>
> // encoding / toString values
> enum UrlFormattingOption {
> None = 0x0,
> RemoveScheme = 0x1,
> RemovePassword = 0x2,
> RemoveUserInfo = RemovePassword | 0x4,
> RemovePort = 0x8,
> RemoveAuthority = RemoveUserInfo | RemovePort | 0x10,
> RemovePath = 0x20,
> RemoveQuery = 0x40,
> RemoveFragment = 0x80,
> // 0x100 was a private code in Qt 4, keep unused for a while
> StripTrailingSlash = 0x200
> };
>
> enum ComponentFormattingOption {
> FullyEncoded = 0x,
> DecodeSpaces = 0x1000,
> DecodeUnambiguousDelimiters = 0x2000,
> DecodeAllDelimiters = DecodeUnambiguousDelimiters | 0x4000,
> DecodeUnicode = 0x8000,
>
> PrettyDecoded = DecodeSpaces | DecodeUnambiguousDelimiters |
> DecodeUnicode,
> MostDecoded = PrettyDecoded | DecodeAllDelimiters
> };
> Q_DECLARE_FLAGS(ComponentFormattingOptions, ComponentFormattingOption)
> #ifdef qdoc
> Q_DECLARE_FLAGS(FormattingOptions, UrlFormattingOption)
> #else
> typedef QUrlTwoFlags
> FormattingOptions;
> #endif
>
> QUrl();
> QUrl(const QUrl©);
> QUrl&operator =(const QUrl©);
> #ifdef QT_NO_URL_CAST_FROM_STRING
> explicit QUrl(const QString&url, ParsingMode mode = TolerantMode);
> #else
> QUrl(const QString&url, ParsingMode mode = TolerantMode);
> QUrl&operator=(const QString&url);
> #endif
> #ifdef Q_COMPILER_RVALUE_REFS
> QUrl(QUrl&&other) : d(0)
> { qSwap(d, other.d); }
> inline QUrl&operator=(QUrl&&other)
> { qSwap(d, other.d); return *this; }
> #endif
> ~QUrl();
>
> inline void swap(QUrl&other) { qSwap(d, other.d); }
>
> void setUrl(const QSt
Re: [Development] API review for the new QUrl
On 10/31/2011 05:42 PM, ext Thiago Macieira wrote: > (...) >>>- QUrlQuery does not keep the order of the items (it's kept in a hash). >>>Is >>> >>> the order important? >> >> I would prefer if the order was kept; e.g. for using OAuth, the >> parameters need to be sorted in alphabetical order and then that string >> needs to be hashed; changing the order in that case would also change >> the hash value and would result in an error when using OAuth. >> >> So I think there are use cases where parameter ordering is important. > > I see. Do you have any OAuth testcases I could add to make sure QUrlQuery > works as expected? not yet, unfortunately. We might come up with one once we proceed with OAuth, though (see the OAuth task at -> https://bugreports.qt.nokia.com/browse/QTBUG-6229 ). Peter > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-10481: Adding support for DNS SRV lookups
Hello, On 10/26/2011 03:15 PM, ext Jeremy Lainé wrote: > Some time ago a bug [1] was filed against Qt pointing out the fact there that > Qt4 has no API for doing DNS SRV lookups. Such lookups are important for > implementing both XMPP and SIP applications, and as such I wrote an > implementation for the QXmpp [2] project which has been in use for over a > year. I got some initial feedback from Qt developers both on the merge > request on gitorious [3] and on IRC, and I adjusted the code accordingly. > > I would like to get some further feedback on the API / implementation in > order to hopefully get the code merged into Qt, and have submitted it to > gerrit for review [4]. Comments are welcome! While I like the API and the naming proposed by Shane, I wonder if we need some more general API for doing other DNS lookups, like e.g. TXT records or the new record types needed for DNSSEC? Could we maybe have an overload for QHostInfo::lookupHost() instead of a new class, or would that be to generic when it comes to parsing the response? Regarding Olivier's comment: I'd rather prefer the low-level API. I understand the point of convenience when having that logic in a connect() call, however I am not convinced it covers all the use cases: * Maybe at some point you might want to parse DNS responses "by hand" (e.g. for DNSSEC?) * Some anti-virus software apparently stores versioning information directly in DNS responses so the client does not need to contact the server all the time * another (admittedly creative) example of using DNS TXT records is the Google certificate checker at -> http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html Peter > > Jeremy > > [1] https://bugreports.qt.nokia.com/browse/QTBUG-10481 > [2] http://code.google.com/p/qxmpp/ > [3] http://qt.gitorious.org/qt/qt/merge_requests/887 > [4] http://codereview.qt-project.org/7475 > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] proposing Richard Moore as approver
Hello, hereby I would like to propose Richard Moore as approver for the Qt project. Rich has made numerous high-quality commits to the Qt SSL code and knows Qt very well, being a KDE contributor since the very beginning. Shane Kearns and Martin Petersson second this proposal. Please raise any concerns you might have about this until 22nd of November 2011 (see the guide lines at http://wiki.qt-project.org/The_Qt_Governance_Model#How_to_become_an_Approver). Regards, Peter -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/03/2011 12:40 PM, ext Jeremy Lainé wrote:
> Based on some initial feedback I received regarding DNS SRV support in Qt, I
> have refactored my proposed code and introduced a "QDnsResolver" class which
> I would like to submit for API review. The point of this class is to provide
> a QNAM-style asynchronous API to perform DNS lookups.
>
> The resolver object itself looks like:
>
> class Q_NETWORK_EXPORT QDnsResolver : public QObject
> {
> Q_OBJECT
>
> public:
> QDnsResolver(QObject *parent = 0);
> ~QDnsResolver();
>
> QDnsReply *lookupService(const QString&serviceName, const
> QString&domainName);
>
> private:
> Q_DECLARE_PRIVATE(QDnsResolver)
> };
Without having looked at the code in detail, in general I like the idea
of having a low-level DNS query class in Qt.
As Thiago pointed out on IRC, it would complement QHostInfo, as the
latter class uses queries to the system to resolve the name (which might
end up in looking up the name via the hosts file, via DNS, or via other
configuration files).
>
> Currently, there is only lookupService() to perform DNS SRV record types, but
> it would be easy to add lookupText() for TXT records, etc.
>
> An open question: should we have multiple lookupXXX() methods, or a single
> lookup() which takes a QDnsRequest?
It might make sense to have a generic method for querying any type of
DNS; but then would we need a QDnsRequest class which might be overkill
if we only support SRV and maybe TXT records short term? How complex can
a DNS query possibly get so it would justify creating an own class? I am
not sure about (one generic method plus request class) vs. (several
specific methods) yet...
Peter
> (...)
--
Qt Developer Days 2011 – REGISTER NOW!
October 24 – 26, Munich
November 29 – December 1, San Francisco
Learn more and Register at http://qt.nokia.com/qtdevdays2011
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/03/2011 04:12 PM, ext Thiago Macieira wrote: > (...) > The DNS query is not the problem. A query is always composed of a domain name > being queried, along with the DNS class (Internet, no one uses anything else > for real purposes) and the record type. For the record type, it's very easy to > just list all types and also say that the user can use other types from the > DNS documentation. See the ns_type enum in /usr/include/arpa/nameser.h [1]. Yes, the query is quite simple, that is why I was wondering whether we need a class for it at all. > > The problem is the DNS reply. Each query type contains a different kind of > data > structure that would need to be parsed. It gets very complex very quickly if > we want to present the data in a nice, C++ class. I am wondering: According to Jeremy it would be best to have separate classes for different record types; however the way QDnsReply is designed it looks like a generic class for DNS replies with special accessors for specific records like serviceRecords(). @Jeremy: Do you think this is feasible now? I.e. could we have all the accessors combined in one class and have a generic accessor for the QString cases? Or would we have too many methods in the class for the special cases at some point and we should rather have special classes? Peter > > A 4 bytes containing an IPv4 address (QHostAddress) > NSa domain name (QString) > CNAME a domain name (QString) > SOA two domain names and five integers > PTR a domain name (QString) > MXan integer and a domain name > TXT text (QString) > 16 bytes containing an IPv6 address (QHostAddress) > SRV two integers and a domain name > A6an integer, an IPv6 address and a domain name > DNAME a domain name (QString) > TKEY, TSIG? > > And that's just listing the ones that I thought we'd like to support. CNAME > and DNAME are likely not to be the query, but they might appear as part of the > reply. > > [1] a that suffers from the "creat" syndrome. > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/03/2011 08:32 PM, ext Jeremy Lainé wrote: > > Le Nov 3, 2011 à 7:10 PM, Peter Hartmann a écrit : > >> On 11/03/2011 04:12 PM, ext Thiago Macieira wrote: >>> (...) >>> The DNS query is not the problem. A query is always composed of a domain >>> name >>> being queried, along with the DNS class (Internet, no one uses anything else >>> for real purposes) and the record type. For the record type, it's very easy >>> to >>> just list all types and also say that the user can use other types from the >>> DNS documentation. See the ns_type enum in /usr/include/arpa/nameser.h [1]. >> >> Yes, the query is quite simple, that is why I was wondering whether we >> need a class for it at all. >> > > Probably not. In the end I ended just storing the request type and encoded > query domain in QDnsReplyPrivate. I have not yet exposed it for lack of a > good accessor name. Any suggestions? How about queryType() or requestType() and queryHost() or requestHost()? (I wouldn't go for queryDomain() because that doesn't sound fit for reverse lookups). The RFC and Wikipedia etc. seem to use both 'query' and 'request'... > (...) > I changed my mind about the replies after all, I find having a single > QDnsReply class works well so far (as you probably noticed, I added support > for MX and TXT records). Do you see a compelling reason to change this? I am happy with having one QDnsReply class; I think we can get pretty far with some special accessors for SRV and other records, and one generic accessor for simple (QString) and unsupported cases. Then whoever wants to read a currently unsupported response format needs to parse the response string himself, which IMO is not that bad. We can then in the future extend the class with more special accessors if need be. > > Thanks to Shane's feedback the win32 code now compiles and passes all tests. > > Jeremy -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/04/2011 11:05 AM, ext Thiago Macieira wrote: > On Friday, 4 de November de 2011 10:36:29 Peter Hartmann wrote: >> I am happy with having one QDnsReply class; I think we can get pretty >> far with some special accessors for SRV and other records, and one >> generic accessor for simple (QString) and unsupported cases. Then >> whoever wants to read a currently unsupported response format needs to >> parse the response string himself, which IMO is not that bad. >> We can then in the future extend the class with more special accessors >> if need be. > > There's no way to provide the unsupported formats in QString. It would need to > be QByteArray and, even then, it's useless if it contains a compressed domain > name. True, QByteArray then, but why would it be useless? You would just need to parse the response itself if the format is not supported, which would be easy for TXT, SOA, A6 etc. For CERT and other DNSSEC types you would have to do the parsing yourself (e.g. create a PGP key from the raw data), but at least it would be possible. Btw. I think we need the generic accessor anyway because you never know what the format of a TXT response looks like. Q3Dns allowed that only for TXT records, but IMO it would be better to always have an accessor to the raw response data, or at least if the query type is unknown. > > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/04/2011 10:15 AM, ext André Somers wrote: > (...) > The more I think about it, the more I think it is important to fix this: > who is responsible for the lifetime of the QDnsReply object? > > This API does not make that clear. I like the pattern in itself (also in > QNAM), but I do think it would be an improvement if we were to use a shared > pointer to the reply object. That at least makes clear who has ownership of > the object, and prevents memory leaks when people don't realize they are > supposed to delete the object. Good point, maybe we could return a QSharedPointer; I could imagine that often QNetworkReply pointers returned by QNetworkAccessManager are not deleted at all... > > Alternatively, perhaps a look at QFuture would help. QFuture is another way > results that are not yet ready are handled in Qt, but this time it is > returned as a value instead of as a pointer. It would be nice we could come > up with a single approach for these kinds of things and use that all over > the place... > > Another concern is the question why you need a QDnsResolver object at all. > It only has a single method, and it does not seem to benefit from it being > a QObject at all at the moment, unless you plan to mimick the API of QNAM > and add signals and slots on the Resolver object itself. If not, then it > might as well just be a static method of the class, or just a method in a > namespace called QDnsResolver or something like that. Currently, the user > will have to instantiate the QDnsResolver object, and call the > lookupService method. It is not so clear what needs to happen to that > instance after that. Can it be savely deleted again while the request is > still running? If we only end up with one generic method for looking up names, then we might not need the class. The API might not look like QNetworkAccessManager and friends anymore then, which would be nice, but is not an absolute requirement I think. > > > Andre' > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 11/09/2011 06:43 PM, ext Jeremy Lainé wrote: > (...) > A/ static QDnsReply* QDnsReply::lookup(QDnsReply::Type, QString); > > pro: easy to connect to the QDnsReply's signal > con: it's entirely up to the user to handle deletion. Judging by your > comments above, I > doubt you favor it? > > or > > B/ static QSharedPointer QDnsReply::lookup(QDnsReply::Type, > QString); > > pro: memory ownership is explicit > con: how used are our users to manipulating QSharedPointer with respect to > signals and such? I rather favour option B (lessons learned from QNAM), because I think option A might lead to undeleted replies, which is what we experienced in the case of QNetworkReply *QNetworkAccessmanager::get(...). We probably can mitigate the complexity introduced by QSharedPointer by having a simple example in the documentation. However if people more favour option A, that would not be a problem for me either. Peter > > Jeremy > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] proposal: security mailing list
Hello, I would like to propose the introduction of a low-traffic security mailing list for posting security patches for Qt. Right now we always need to write a blog post entry with an attached diff (see for instance [1]), but since e.g. SSL certificates get compromised a lot these days, this does not scale that well. So maybe an own mailing list with important security-related updates would be helpful for Linux package maintainers and others. There was the suggestion that this list should be private; personally I rather favor a public list, because usually when creating patches for Qt similar patches have landed in other public repositories already (e.g. Chromium or Mozilla). The reason for that is that most of the security patches were made regarding blacklisting fraudulent certificates rather than fixing memory corruption bugs which should be kept secret. Btw. note that there is also a security issue report form at http://qt.nokia.com/forms/security . Any comments? Regards, Peter --- [1] http://labs.qt.nokia.com/2011/09/07/what-the-diginotar-security-breach-means-for-qt-users-continued/ -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposal: security mailing list
On 11/15/2011 09:30 PM, ext lars.kn...@nokia.com wrote: > (...) > The reason why many other projects have private lists for security issues > is to avoid making zero day exploits widely known. It would most likely be > good to also be able to discuss some of these issues in a more closed > mailing list, not to be less transparent, but to not tell hackers about > the issues before we have a fix. We have that list already internally within Nokia; whenever somebody sends a report via the security issue report form at http://qt.nokia.com/forms/security it will end up on the private security list. We are planning to transfer that list to something @qt-project.org. The plan is to make that list invite-only and the archives private. > > A public announcement list might be needed as well, but for that we could > simply use annou...@qt-project.org. OK, fine by me, then let's use the announce list for security announcements as well. If nobody objects I will write a blog post on http://labs.qt.nokia.com/ the next time there is a security issue, and will say that in the future those things are handled through annou...@qt-project.org. Peter > > Cheers, > Lars > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposal: security mailing list
On 11/16/2011 03:30 PM, ext Alexis Menard wrote: > On Wed, Nov 16, 2011 at 11:21 AM, Laszlo Papp wrote: >>> We are planning to transfer that list to something @qt-project.org.The >>> plan is to make that list invite-only and the archives private. >> >> I am not sure what you mean by invite-only. Could you please >> ellaborate on the precise meaning ? > > A member propose to invite a person, and modulo approval of the others > he/she can join. exactly, just like becoming an approver for Qt. In addition we can CC individuals on a case-by-case basis (and have done so previously). Peter > >> >> In general, I think it would be nice to provide the opportunity for >> people to join, if they can prove the relevant background for instance >> (maybe with 1-2 supporters). > > That's what he meant. > >> >> Best Regards, >> Laszlo Papp >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposing Richard Moore as approver
Within 15 working days, we have received mails from 10 people who second this nomination, and we have not received an objection. So Rich Moore is hereby solemnly declared an approver for the Qt project. Congratulations! Peter On 11/01/2011 04:00 PM, ext Peter Hartmann wrote: > Hello, > > hereby I would like to propose Richard Moore as approver for the Qt project. > > Rich has made numerous high-quality commits to the Qt SSL code and knows > Qt very well, being a KDE contributor since the very beginning. > > Shane Kearns and Martin Petersson second this proposal. > > Please raise any concerns you might have about this until 22nd of > November 2011 (see the guide lines at > http://wiki.qt-project.org/The_Qt_Governance_Model#How_to_become_an_Approver). > > Regards, > > Peter > -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On 12/06/2011 12:32 AM, ext Thiago Macieira wrote: > (...) > The cache, however, could be an issue. Imagine I do a get() from an auxiliary > thread, one that the QNAM and the cache are not affined to. The implementation > would need to read from the cache in one thread and make the data available to > the user, in the QNetworkReply, in another thread. Another interesting thing to note is that AFAIU with WebKit 2 there can be multiple web processes per application, all using the same cache (and cookie jar), so we would need to make the cache usable by several applications at the same time. Maybe Webkit people can elaborate or know how other ports do that... Peter > > This would, however, make a "clean" solution. > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On 12/06/2011 04:56 PM, ext Jonas Gastal wrote: > (...) >>> That's a slightly different problem. With WebKit 2, we have different >> processes, >>> so different instances of QAbstractNetworkCache. The problem then is not >> to >>> make the class be thread-safe, but to make the cache methodology be >> multi- >>> process-safe. Yes, it was my exact point to note that this is a different problem; and of course QMutex does not help here. > Sorry if this is a stupid point, but there is a pretty standard mechanism > for > multiprocess "mutexes" in the form of ".lock" files. Isn't this an obvious > and > acceptable solution(to that part of the issue)? They have the same up/down > sides of actual mutexes. It might be; other options include QSharedMemory or whatever boost::interprocess::file_lock does. My point was more that there might be more logic needed on top of the disk cache, because we had plans to keep some items in memory (as browsers do), which we then maybe would need to synchronize; in addition we would need something for a persistent cookie jar where you do not want to read from / write to disk for each single cookie. So my point was: Let's keep the WebKit2 use case in mind when redesigning the cache / persisting the cookie jar etc. Peter > > Gastal. > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Qt Developer Days 2011 – REGISTER NOW! October 24 – 26, Munich November 29 – December 1, San Francisco Learn more and Register at http://qt.nokia.com/qtdevdays2011 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork changes from QtDD SF 2011
On 12/06/2011 04:53 PM, ext Alexis Menard wrote:
> (...)
> - setCookieFromUrl to not be magic. It may removes/update cookies and
> therefore If I implement a persistent storage it would be nice to know what
> is added/removed/updated from the internal list.
> - I need some "hooks" whenever something is added/removed/updated from the
> internal list of cookie stored by QNetworkCookieJar. Basically all the black
> magic done by QNetworkCookieJar, I need to know about it so I can update
> accordingly where I store my cookies (read a SQL database). I was thinking
> that a couple of virtual method should be fine, for example :
>
> void writeCookie(const QNetworkCookie&foo) {
>
> // Store into my database
>
> // Call the base class.
> QNetworkCookieJar::write(cookie);
>
> }
yes, so as Alexis already said, we plan to introduce new virtual methods
virtual void insertCookie(...)
deleteCookie(...)
updateCookie(...)
cookie(...)
which by default just do what QNetworkCookieJar currently does, i.e.
manage everything in memory. In addition we can expose the security
check as a new function "isCookieAccepted()" or so.
So that way one could implement a backend of choice, which could also be
persistent; and we could have backends as Qt add-ons.
The burden of keeping everything in sync regarding several processes in
Webkit 2 would be put on the implementor of that class; the base class
wouldn't be able to deal with that. But since Webkit people plan to have
a persistent cookie jar anyway I guess this would be fine.
Peter
>
> The base class just adding it into the list.
>
> - Maybe put the security filtering into a separate virtual function (to make
> setCookieFromUrl less magical, even if the latter will call that function).
> Make the API looks nicer to me.
>
> In the ideal world an add-on of Qt should give the possibility to have a
> persistent storage built in (Mac OS has an API cross OS/apps for that) for
> example a subclass of QNetworkCookieJar which already implement a SQL storage
> for example.
>
>> * Need a default persistent cookie jar: possibly?
>> * Talk to WebKit guys, see if we can make an addon based on their cookie jar
>>
>> Application proxy:
>> * Use system proxy by default
>>
>> System proxy config:
>> * Global proxy config needs to be in network manager/connection manager
>> so there is a known place to fetch it before system proxies can be
>> supported on non-Windows/MacOS
>>
>> QNetworkProxyFactory:
>> * queryProxy() needs to be documented that it must be thread-safe
>> * proxyForQuery(): unlock mutex before calling user code
>>
>> QSharedPointer:
>> * Use for all three (disk cache, cookie jar, qnam) so that the user can
>> keep a ref around if they want (also for the static methods)
>> * Make QSharedPointer be able to delete properly with a forward declaration
>> * QObject::connect needs to be able to take a QSharedPointer
>> * QObject::connect needs to be able to take a QWeakPointer
>>
>> Ultra long term (Qt6): Fix QIODevice to do zero-copy
>> ___
>> 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
--
Qt Developer Days 2011 – REGISTER NOW!
October 24 – 26, Munich
November 29 – December 1, San Francisco
Learn more and Register at http://qt.nokia.com/qtdevdays2011
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze date?
On 12/14/2011 06:42 PM, ext Thiago Macieira wrote: > On Wednesday, 14 de December de 2011 18.12.21, Stephen Kelly wrote: >> Ok, well let's start the list: >> >> https://wiki.qt-project.org/5.0_Feature_Requirements my addition for network (feel free to point out more): == Network == * SSL errors (+ OCSP etc.): make it possible to display SSL errors without stalling QNetworkAccessManager (http://bugreports.qt.nokia.com/browse/QTBUG-19032) * Authentication: make it possible to display authentication dialog without stalling QNetworkAccessManager (https://bugreports.qt.nokia.com/browse/QTBUG-16251); this is obviously closely tied to above task * remove QHttp (https://bugreports.qt.nokia.com/browse/QTBUG-22750) * rewrite cookie jar (https://bugreports.qt.nokia.com/browse/QTBUG-23145) Peter >> >> One thing we could do is: >> >> 1. Let people populate the list >> 2. Review the list for plausibility in a reasonable timeframe >> and personal availability. >> 3. Estimate the time for the responsible people to get the work done. >> 4. Schedule feature freeze based on that. >> 5. Features that unfortunately don't get finished by then don't make >> it into 5.0, and possibly .x. >> >> That's just an idea of how to make progress though. Making a scheduling >> decision without any idea of what needs to be done in that timeframe doesn't >> really make sense. > > That's why I started the thread. We need to know what we need to do so we can > make a scheduling decision. Or, alternatively, we need to decide what we can > do given the schedule. > > I also oppose to your item #5 above. I don't want to see anything on a page > called "5.0 requirements" that can be postponed. I want *only* the stuff that > *must* go into 5.0, i.e., what cannot go into 5.1 or a later release until > 6.0. > > If we reach the feature freeze date and a requirement isn't complete yet, > we'll need to make a call whether to delay the freeze or not. This is > something we'll do only for 5.0, as for any future releases, anything can be > postponed. That also means we don't have "feature requirements", but only a > wish-list. [That's between us developers; in public communication we may call > them differently] > > For those things that can be postponed, we should have a separate roadmap > page. We can also start collecting ideas for future releases. > Backward incompatible change freeze? (Yes) >>> >>> See above on both SIC and BIC changes. >> >> Right. This would be soft-frozen probably at RC or beta time. > > Depending on whether you referred to source or binary incompatible changes; > and for the source ones, it's understood it applies to new features only. > >>> Of the "I can't judge" QtWidgets features above, considering that module >>> is >>> in Done state and we have a source-compatible requirement for 5.0 for >>> existing features, I would wager that they are not Qt 5.0 requirements. >> >> Yes, but there are also lessons which we need to ensure are not forgotten so >> that we have useful API for QML. An example is the QCompletion stuff. Doing >> that 'properly' and in a future-proof, QML compatible way probably actually >> depends on itemmodels getting new features, such as a virtual search() >> method to supercede the match() method. That's just an example. There may >> be others. > > I agree. However, we'll never finish finding new requirements or need to > improve > the API, so we need to make a cut somewhere based on our best understanding. I > might be an optimist here, but I'd have expected all these studies where we > need new API to have completed by now. We're 5 months into the 5.0 cycle, 1 > year into the QtDeclarative API, 6½ years since ItemViews and the rest of the > Qt 4 API. > > > > > ___ > 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] QHttp removal
On 12/26/2011 11:08 AM, ext lars.kn...@nokia.com wrote: > (...) >> I'd say, move that class in qhttpheader_p.h > > Yes, let's make it private (or get rid of it if possible). For those that > need/use QHttpHeader (and/or QHttp), we can provide the code as a small > static library that you can include in your code base. I also like first making the parts still in use private; getting rid of it completely is a bigger task, as it requires rewriting parts of the HTTP socket engine and QAuthenticator IIRC. Peter > > 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] QHttp removal
On 01/03/2012 01:07 PM, ext Thiago Macieira wrote: > On Tuesday, 3 de January de 2012 09.53.41, Jonas M. Gastal wrote: >> As for removing them entirely yes, it would require changes in the HTTP >> socket engine and QAuthenticator. But given that both of them use >> QHttpResponseHeader I see no reason to duplicate the code in both classes, >> perphaps it would be preferable to simply strip the not used functionality >> from the existing QHttpResponseHeader class? > > I'm pretty sure that the functionality exists in QNetworkRequestPrivate plus > the feeding of line by line, found in the QNAM's HTTP engine. We don't need to > keep even the QHttpResponseHeader class. I also think the only reason for the old header classes from QHttp to still exist is that it is used inside QtNetwork, ideally we want to get rid of them altogether and have only one code path for the header files (i.e. the one in QNAM)... Peter > > > > > ___ > 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] Hacking guide for Qt's SSL Support
On 01/01/2012 04:51 PM, ext Andreas Aardal Hanssen wrote: > (...) > The other options I imagined were GnuTLS [*], and using native SSL support > should that exist. > > Today the backend separation is still around but it only complicates the > code unless there truly are other backends to support. I don't know GnuTLS at all, but I would say if there was another backend we might want to support then it is NSS, as it is used by Mozilla and Google Chrome on Linux, so I assume it to be stable and well tested, + they seem to care a lot about blacklisting certificates etc. But anyway, this is more a theoretical thought these days, I don't see another backend being implemented anytime soon... but I am still in favour of keeping the distinction between what is common SSL logic and what is OpenSSL specific. Btw. nice Wiki page, Rich :) Peter > > What are your thoughts on this? > > Andreas > > [*] http://www.gnu.org/software/gnutls/ - dropped because it clearly staged > it was in early Alpha stage at the time, which I find to be really scary > for a security framework, and currently I don't think the licensing looks > very interesting. If OpenSSL does the job then why use GnuTLS? > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] API review for a new QDnsResolver class
On 01/06/2012 06:46 PM, ext Jeremy Lainé wrote: >> - finalise the class name (I think QDns was suggested) >> > > Could we get this point settled once and for all? My suggestions: > > - QDnsLookup (my preferred one, as the object represents a lookup and its > result) I like the name too... > - QDnsInfo (similar to QHostInfo) > - QDns > > Jeremy > ___ > 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] fixing name of QNetworkAccessManager::createRequest
On 01/13/2012 02:10 PM, ext Mathias Hasselmann wrote: > (...) > Surely startRequest() would have been a better name. > But really not sure it is worth the hassle of changing it. > Still Robins suggestions shows a practical approach. I don't really think it is worth changing it, I think for 5.0 so far we only broke source compatibility if the name or signature was plain wrong (8ef86d05f199ebab216da43d5e0a9dc322b657b3 or bf7f17060773803f332e8c729a70f47b94243890), not in cases where it could have been named better... Peter > > Ciao, > Mathias > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Does someone have plans to start working on the OAuth integration?
On 01/25/2012 09:22 AM, ext tero.aij...@nokia.com wrote: > ...Mentioned on the bug here: > https://bugreports.qt.nokia.com//browse/QTBUG-6229 > Or has the work even been started already? > > In case not, does e.g. kqOAuth already work with Qt5? It would be nice if we could have kQOauth ([1]) as an add-on module in Qt ([2]); I am in contact with the kqOAuth author and from what I can remember he liked the idea. I guess that this would be all it takes to make it work with Qt 5, but I have never verified that. Also, talking about OAuth is a bit confusing because it comes in two versions: OAuth 1.0a, which you want to use with a 3rd party library like kQOAuth, and OAuth 2, which I believe is simple enough to do on top of QNetworkAccessManager. Both versions are currently in use, while I think new APIs tend to use OAuth 2 more. Here some examples, I hope they are still up to date: OAuth 1.0a: Twitter, Flickr, Dropbox OAuth 2:Facebook, Youtube, Foursquare Peter [1] http://www.d-pointer.com/solutions/kqoauth/ [2] http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] RFC: Qt Security Policy
On 10/09/2012 01:07 AM, Giuseppe D'Angelo wrote: > (...) >> * Security issues should not be reported via the normal >> bugreports.qt-project.org tracker, but should instead be sent to >> security at qt-project.org. > > This requires advertising such address properly, on the main > qt-project website, on the wiki, etc. Back in Nokia days we had a web form on the "contact us" web page for security issues (see also the thread from last year -> http://www.mail-archive.com/development@qt-project.org/msg00401.html). Maybe we could have a web form or the mail address mentioned at qt-project.org? And maybe Digia wants to somehow link to that on their web page as well? The proposal looks good to me (I had read it before it was posted here); one more thing: I see the "Blog" link on qt-project.org now links to the Digia blog. Shouldn't it link to planet.qt-project.org? Then security announcements could be made public through a blog post as well, and mails on announce@ could link to the post if necessary etc. Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtNetwork: using system proxy by default
Hello, I remember this has been discussed before, but yet again: How about using the system proxy by default, at least on some platforms or by configure switch? Right now every app developer has to call QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to use the system proxies. On desktop you might want to avoid this depending on your app, but on mobile (e.g. Blackberry) it might happen that you just have to use the system configuration and it will not work without it. IMO there are 4 options: 1. leave as it is, tell everybody to call above method in their app 2. just #ifdef for the platforms where it should be used automatically 3. introduce a configure switch "-use-system-proxy" or so (default no) 4. enable usage of system proxy globally 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons. If people think 3. is cleaner that is fine with me as well. As Shane told me, using the system proxy on Windows might lead to several seconds of delay until the synchronous method that determines the proxy returns, so for now 4. seems too risky. Please suggest / comment etc. Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
What I forgot to say in my first mail: We would want to use that in 4.8, where we don't want to change the default behaviour anyhow. How about option 3 below, where the default can be set to "yes" in Qt5 globally or per platform once we are confident it works? The benefit of that option is that it can be easily backported to 4.8 and would not change behaviour, but whoever wants to use it can opt-in. Peter On 10/11/2012 03:12 PM, Peter Hartmann wrote: > (...) > 1. leave as it is, tell everybody to call above method in their app > 2. just #ifdef for the platforms where it should be used automatically > 3. introduce a configure switch "-use-system-proxy" or so (default no) > 4. enable usage of system proxy globally > > > 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons. If > people think 3. is cleaner that is fine with me as well. As Shane told > me, using the system proxy on Windows might lead to several seconds of > delay until the synchronous method that determines the proxy returns, so > for now 4. seems too risky. > > Please suggest / comment etc. > > > Peter > > - > This transmission (including any attachments) may contain confidential > information, privileged material (including material protected by the > solicitor-client or other applicable privileges), or constitute non-public > information. Any use of this information by anyone other than the intended > recipient is prohibited. If you have received this transmission in error, > please immediately reply to the sender and delete this information from your > system. Use, dissemination, distribution, or reproduction of this > transmission by unintended recipients is not authorized and may be unlawful. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms
Hello, On 11/07/2012 01:26 PM, Laszlo Papp wrote: > (...) > I have always been surprised why there has no been more work done on the > CI front towards the very common ARM platform. I had to catch common ARM > issues on Harmattan and elsewhere (not only mobile phone material) that > pretty much came up for all the cases. Such things would have been > really nice to be caught by CI. we (RIM) currently have an own Jenkins setup which builds Qt for BlackBerry 10 (ARM and x86), and also runs auto tests (currently only QtCore classes unfortunately). The process of making that Jenkins node public including build / test logs etc. is currently stuck in a company security check. But our plan is absolutely to have test and build results public, and make the setup stable enough to at some point tie into the Qt CI infrastructure. Peter > > Laszlo > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] binary compatibility promise (was: Re: Frameworks on Mac?)
On 11/23/2012 12:12 AM, André Pönitz wrote: > (...) > The reality is that this guarantee often enough does not hold in > practice. Vendors of "binary" Qt based application typically test their > setup against one specific (often enough patched) version of Qt which > is then shipped with the application. Users are not expected to switch > Qt versions, except when upgrading the whole application. Insofar are > rules like "we can't add symbols in patch releases" not much more then > self-inflicted pain without measurable gain. This situation is different on mobile (and I guess embedded as well); for BlackBerry10 we have one version of Qt on the device and often cross-compile apps with another version of Qt; so we depend on the binary compatibility promise for patch releases (and in fact were bitten by the new symbols as well when people reported their app was not launching with "unknown symbol: _ZNK20QFutureInterfaceBase4refTEv" etc.). Peter > >> Isn't it true that duplicate copies of Qt in every application will >> result in duplicate copies being loaded into RAM too? > > Better double memory consumption then unexpected behaviour changes. > > Andre' > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] binary compatibility promise
On 11/23/2012 11:11 AM, Poenitz Andre wrote: > Peter Hartmann wrote: >> On 11/23/2012 12:12 AM, André Pönitz wrote: >>> (...) >>> The reality is that this guarantee often enough does not hold in >>> practice. Vendors of "binary" Qt based application typically test their >>> setup against one specific (often enough patched) version of Qt which >>> is then shipped with the application. Users are not expected to switch >>> Qt versions, except when upgrading the whole application. Insofar are >>> rules like "we can't add symbols in patch releases" not much more then >>> self-inflicted pain without measurable gain. >> >> This situation is different on mobile (and I guess embedded as well); >> for BlackBerry10 we have one version of Qt on the device > > Do you intend to upgrade this version of Qt that's installed on the device > without upgrading the applications using it? yes, e.g. device updates and 3rd party apps in the store. Peter > > Andre' > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating roquetto for approver status
On 12/03/2012 04:48 PM, Thiago Macieira wrote: > (...) >>> >>> Would anyone like to second? >> >> +1 from me >> Disclaimer: I'm at KDAB, like he is, too. > > +1 from me > Disclaimer: I'm not at KDAB, but I am Brazilian like Rafael :-) +1 from me no disclaimer :) Peter > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] requesting an own 4.8-blackberry10 branch on gitorious
Hello, would it be possible to get an own 4.8-blackberry10 branch on gitorious in the qt repo (https://qt.gitorious.org/qt/qt), similar to the 4.8.0-symbian branch that still exists? The thing is for BlackBerry 10 we are working as close to upstream (i.e. 4.8 branch) as possible, but due to some features we needed that are hard to get into 4.8 (e.g. https://codereview.qt-project.org/#change,39135) and turnaround time for getting patches into Qt 4 (+ getting them into Qt 5 first), it would be good if we had an own dedicated branch for it. We could point people to it in case they want to compile Qt themselves for BlackBerry 10, and make sure everybody working on it (us and KDAB) is using exactly the same branch. Alternatively I guess we could just clone the repo into a team clone. Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/17/2012 03:24 PM, Turunen Tuukka wrote: > (...) > We can discuss this, but personally I am not that fond of creating > platform specific branches. I think the drawbacks of these clearly > outweight the benefits in long run. Could you please outline the drawbacks? In case you are thinking about diverging from the 4.8 branch and not upstreaming commits: We are trying hard to upstream everything we have; however sometimes we just need a patch quickly in our device builds, then we just cannot wait for it to be in the 4.8 branch (e.g. https://codereview.qt-project.org/#change,42315). This branch (a release branch if you will) exists already internally, the question is just whether we are going to have it as part of the normal qt repo or as a team clone. > > If your problem is mainly turnaround time for getting things in it may be > due to many being busy with getting Qt 5.0.0 out. In general we are still > welcoming improvements to 4.8 as long as they are not behavioral or public > API changes. Turnaround time is one of the problems (not blaming anyone); another problem is that we change behaviour deliberately. In that case the commits are public, but not integrated into the 4.8 branch. I guess https://codereview.qt-project.org/#change,39135 is such a commit; it has been around for a long time now, and I don't know whether it ever will be in 4.8, but we needed it in our internal repo so I just cherry-picked it. Peter > > Yours, > > Tuukka > > > > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 12:26 PM, Oswald Buddenhagen wrote: > On Tue, Dec 18, 2012 at 10:00:25AM +, Vladimir Minenko wrote: >> How do we proceed now? More comments? Some details for the expressed doubts? >> Some actions? >> > i created the branch 4.8.4-bb10 (which is also the version number you > should announce your release as). members of the group "Blackberry10 > Branch Owners" (which you and peter are the admins of) may direct-push > and submit changes into it (adjustments possible at any time). > > for the next release you'll obviously need the next vendor-release > branch. provided you actually use it to "start from scratch" (by > rebasing on top of the latest official release), this is cleaner than a > permanent vendor branch where you only merge from upstream (and get > yourself a fine mess of already upstreamed and still proprietary > patches). if the number of patches which are not supposed to be > upstreamed is is too big, going for the permanent vendor branch would be > more reasonable, though. Thanks for setting up the branch; however, would it be possible to get a 4.8-blackberry10 branch (without reference to the patch release number)? We are not really releasing our own versions of 4.8.4, 4.8.5 etc., but have our own release cycle for NDK and device images, which is not related to the Qt 4 release cycle in any way. So that branch to be created where we make "releases" (builds for NDK / devices) from is always the 4.8 branch + some not yet upstreamed commits; a branch called 4.8-blackberry10 would suit that better IMO. We are never actually "starting from scratch" for new patch releases; in fact, the patch release number (i.e. whether the libs are called e.g. *.4.8.4 or *.4.8.5) is just a minor detail to us. Also (nitpicking), maybe the suffix should be "-blackberry10" instead of "-bb10", because I guess not everybody knows what "bb10" stands for. Peter > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 12:05 PM, Sean Harmer wrote: > (...) >> In case we decide to proceed with creation of a vendor branch, is it >> planned to be a temporary solution or something permanent? some months ago, I was confident that this would be something temporary; unfortunately, practice has shown that so far we always had a few commits (1-10) that we needed to "short-circuit" into our branch because some internal team needed a commit urgently (maybe people that have worked on the N9 remember that situation). So I don't expect that branch to go away anytime soon, to be honest. > > I suppose that entirely depends upon what gets committed there. The general > idea is to keep this branch as the minimum set of patches needed for this > platform that cannot be merged into the Qt mainline. Peter already mentioned > one such patch. Yes, this is another reason why the branch will most likely not become redundant... Peter > > The case of expediting patches in this branch is to allow this to happen in > the open in the spirit of the Qt project. Wherever possible the idea is to > upstream the patches into the Qt mainline so that the vendor branch remains as > close as possible to the official Qt Project version. > > Vladimir and Peter may have more to add of course. > > All the best, > > Sean > -- > Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts - Platform-independent software solutions > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 07:13 PM, Oswald Buddenhagen wrote: > On Tue, Dec 18, 2012 at 03:54:20PM +0100, Peter Hartmann wrote: >> Thanks for setting up the branch; however, would it be possible to get a >> 4.8-blackberry10 branch (without reference to the patch release number)? > >> We are not really releasing our own versions of 4.8.4, 4.8.5 etc., but >> have our own release cycle for NDK and device images, which is not >> related to the Qt 4 release cycle in any way. >> > this is immaterial. you are at some point merging from upstream, which is > also when you should "rebase" your version number. this thinking is also > reflected in vladimir's questions about the versioning. > also, consider that users want to think in terms of "upstream release + > minimal delta", not "rolling release based on older upstream". this is > predestined for a rebase workflow. also, for actually upstreaming your > patches, you need to rebase them anyway. latest when you have conflicts, > you'll really "enjoy" using a non-rebased branch (because you can > resolve twice or thrice - once to merge upstream, once to submit > upstream, and in the worst case once more to merge back the upstreamed > version) - and after some time you'll have a history with conflicted > merges and duplicated commits all over the place, where it's really hard > to find out where something comes from and what was already upstreamed. > given the low number of unmergable vendor patches you are aiming at, > you'd really do yourself and everyone else a favor by rebasing. > > but if you are the s/m type, you can have your long-living vendor > branch. ;) You are completely right about rebasing - that is exactly what we do currently: We rebase our internal branch on top of the upstream 4.8 branch regularly (at least once a week). Where I don't follow you is why we would need several branches, each one based on a patch release, for that; IMO we just need one branch (4.8-blackberry10) that we can rebase periodically on top of the upstream 4.8 branch. So yes, long-living vendor branch please :) Peter > >> Also (nitpicking), maybe the suffix should be "-blackberry10" instead of >> "-bb10", because I guess not everybody knows what "bb10" stands for. >> > somebody who doesn't know it wouldn't care about that branch to start > with - and most our branch names are not exactly self-explanatory to the > uninitiated. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] requesting an own 4.8-blackberry10 branch on gitorious
On 12/18/2012 10:06 PM, Oswald Buddenhagen wrote: > (...) > oh. eh. this is somewhat more extreme than expected. in fact, your > branch is everything *but* a long-living branch - it's basically a > scratch branch which is recreated every few days. the problem with > rebasing is that you "detach" the actual history, so your tags are > floating in limbo (provided you make tags at all). that's why i > suggested a branch per upstream release. but if you rebase that often, > this becomes pointless of course (you'd need a separate branch per > rebase). > > there you have your 4.8-bb10 branch where *only* direct pushing (incl. > forced pushes) is enabled. > i'll leave it at noting that this is somewhat weird, and that "the > project" may still decide that this doesn't belong into the upstream > repo. Thanks for creating the branch. If nobody objects within the next days, I will start using it... To clarify: We rebase often on top of upstream because that is where KDAB's and our bug fixes go. Our bug fixes go there because several times now we had a situation where a commit was made in the internal repo, then internal teams started relying on it; at some point later upstream review turned out "you cannot do it like that". Then we are stuck with a bad internal commit, and resolving such a situation takes a lot of effort. So we try to upstream everything as early as possible. Also, practice has shown that the 4.8 branch is quite stable, and we want to get all new commits in early (e.g. security issue, OpenSSL BC problem). I found that rebasing is just easier here than cherry-picking most of the changes manually. Every now and then we need to revert a commit or so, but so far issues has been caught by our (unfortunately still internal) CI system. I cannot remember one case where a bad regression slipped into our device builds so far (though I guess this is more due to the fact that 4.8 is stable rather than our CI system being complete). So if somebody knows how to improve the process taking everything mentioned above into account, I am all ears. And I am aware of the fact that we are re-writing history (and we currently have no tags). Peter > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] BlackBerry Jenkins server (was: Proposal: New list of Qt 5 reference / Tier 1 platforms)
On 11/07/2012 03:30 PM, Peter Hartmann wrote: > (...) > But our plan is absolutely to have test and build results public, and > make the setup stable enough to at some point tie into the Qt CI > infrastructure. Update: the server is now online at http://195.3.174.130/ . Currently it is only running builds for x86 and ARM (scripts at https://qt.gitorious.org/+rim-qt-developers/qt/rim-qtqa), because we cannot attach devices to run tests yet (company security policy etc.). Please do not rely on it in any way (not even the IP), we will be changing the setup the next days / weeks; this is just a notification that there is progress :) Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] issue tracker rights
On 02/12/2013 08:58 PM, Knoll Lars wrote: > I'm very much in favour of opening this up. I think the Qt Project can > only win with a more liberal policy here. While we are at it: Would it maybe be possible as well for any Jira user to add labels? Currently this is apparently only possible for approvers; the thing is we are using the "BlackBerry10" label to group issues that affect our platform (see https://bugreports.qt-project.org/browse/QTJIRA-192)... Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI Network Server Problems
On 03/05/2013 10:09 PM, Richard Moore wrote: > I've tried setting up a test server > with two different versions of ubuntu (the documented one, and the > latest LTS version) but neither works. This makes it impossible for me > to help address the CI failures. I also have some problems: I have my own test server instance, but could not get down to 0 test failures for the network tests so far. Maybe it would be possible to get a snapshot of the virtualised test server image from the CI system? Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] TLS extensions and supplemental data
Looks good! Some comments / questions: - Do you have examples of supplemental data? It seems to me like TLS extensions are more important here, as they are used everywhere already. - re. API: What comes to my mind are the following options: a) generic class QTlsExtension similar to QSslCertificateExtension with name() and QVariant value() and getter "QList QSslConfiguration::tlsExtensions()" (+ respective setter). Depends on whether it is worth to introduce a new class. b) enum in QSslConfiguration (e.g. "QSslConfiguration::TlsExtensionServerName") and getter "QVariant QSslConfiguration::tlsExtension(QSslConfiguration::TlsExtension)" (+ respective setter). Might be better because of less API than a) c) individual getters / setters like "QVariant tlsExtensionServerName()"; that looks like cluttering the API. - re. "On which object should extensions be set/retrieved?": Maybe QSslConfiguration would be the place to set/get extensions, instead of QSslSocket? At least this is where we store things like the session cipher, certificate chain etc. IMO the API is a bit cluttered between those two classes, so I think we should have all of that in QSslConfiguration. - re. "How are the extensions to be set and exposed?": If "There is a requirement to be able to retrieve the far side extension prior to setting extensions", then this sounds like we need a new signal for QSslSocket (and probably later the same one in QNetworkReply). Rich was working on an "encrypted" signal which would be fired after the handshake and before application data was sent, but I guess this would be too late for some extensions then. - re. "One-shot setter supporting a set of extensions, or ability to call addExtension multiple times prior to the extended hello being sent?" I think we could combine it, by having an addExtension taking one single extension and maybe an overload which takes a QList or so. Regards, Peter On 03/08/2013 08:09 PM, Scott Deboy wrote: > I wanted to give folks a heads-up that I'm starting work on defining an API > which will give Qt the ability to retrieve and set TLS extension data sent in > OpenSSL's extended hello. > > I will also be adding support for the ability to send and retrieve > supplemental data messages. > > A Wiki topic has been created to work through the process of defining the API > - please feel free to update/add questions or contribute to the discussion: > > http://qt-project.org/wiki/Improving_TLS_handshake_support > > Thanks much, > > Scott > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting a Minimum Support OpenSSL Version
On 04/16/2013 01:19 PM, Richard Moore wrote: > 2) We could say 1.0.0 is the minimum. +1 This is the de-facto standard already anyhow, at least for me; i.e. I have been acting like "if it works on my PC (1.0.x) and goes through CI (apparently 1.0.x) it is good enough". So I am all for noting this down somewhere: 1.0.x is guaranteed to work and fixes for 0.9.x are welcome (just like fixes for the configure option -openssl-linked, which I think is not tested anywhere either). Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please warn of force pushes...
On 04/22/2013 05:11 PM, Thiago Macieira wrote: >>> And where is it documented for winrt? >> > >> >why should it be? > Because people need to know what to expect if they are going to participate. Just in case somebody is interested: We are rebasing the 4.8-bb10 branch as well. I don't think this is an issue in practice, because not many people are using it and the ones who do know that already I would assume... Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtNetwork performance improvements
Hello, for reference: I have just created a Wiki page about QtNetwork performance improvements at http://qt-project.org/wiki/QtNetwork_performance One interesting quote: "In the particular case of code issuing a network request, the time spent in parsing the HTTP replies, computing SSL keys etc. takes less than 5% of the overall time, i.e. 95% of the time below is spent in waiting for network I/O. In other words: When trying to improve QtNetwork performance, try to shave off network roundtrips and reduce latency rather than trying to improve parsing of HTTP replies / avoiding memcpy etc." Feel free to comment / ask / suggest etc. Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership of QtNetwork
Hello, I also think having 2 maintainers versus 1 maintainer for QtNetwork will not matter much in practice; but if people demand to have one single go-to person I am also fine with either of us taking that role. Peter On 11/04/2013 09:38 PM, Richard Moore wrote: > 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 > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 header diff: QtNetwork
On 11/05/2013 04:38 AM, Thiago Macieira wrote: > On segunda-feira, 4 de novembro de 2013 16:07:32, Thiago Macieira wrote: >> +QByteArray session() const; >> +void setSession(const QByteArray &session); >> +int sessionTicketLifeTimeHint() const; > > Module is fine. > > I'm just wondering if the "session" property should not instead be called > "sessionId". We could have named the methods sessionTicket() and setSessionTicket(), I don't really mind either... Rich? :) > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Fabian Bumberger for Approver Status
+1 disclaimer: I also work for BlackBerry. Peter On 11/19/2013 11:41 AM, Blasche Alexander wrote: > Hello everybody, > > I'd like to nominate Fabian Bumberger for approver status in the Qt Project. > > Fabian has been contributing to QtNfc, QtBluetooth, QtLocation and many more > Blackberry specific topics such as the platform plug-ins. His track record > can be found under: > > https://codereview.qt-project.org/#q,owner:fbumberger,n,z > https://codereview.qt-project.org/#q,reviewer:fbumberger,n,z > >>From my perspective QtBluetooth and QtNfc wouldn't be the same without his >>help. > > I am convinced he will make en excellent approver. > > With regards, > -- > Alex > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Request for new Playground Repo
On 11/20/2013 10:20 PM, Oswald Buddenhagen wrote: > so unless this is going to be a huge beast, maybe qtbase would be > actually a better target? Even better if we could get the PPS parsing code directly into qtbase. As already posted, that comprises only a few files. Is everybody fine with that? We might need a blackberry extras repo for other things later though... Peter - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
