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] 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, 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. >>> >>> Comments? >>>
[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 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] 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] 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] 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] 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] Qt 5.3 header diff: QtNetwork
On 04/22/2014 11:57 PM, Sune Vuorela wrote: On 2014-04-22, Thiago Macieira thiago.macie...@intel.com 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] 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] 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] 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] 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] 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] 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
[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] 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
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
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
[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] 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
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] 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 QListQTlsExtension 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] 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] 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] 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] 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
[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] 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] 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] 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
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
[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] 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
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] 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] 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] 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 Papplp...@kde.org 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
[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] 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 QSharedPointerQDnsReply 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
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/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 QStringserviceName, const
QStringdomainName);
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
