n 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://
g
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
at 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?
>>>
>>> Cheers,
>>> Albert
>>>
&
ion 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 // Titurelstra
U 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...@hartma
+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 thoug
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
t
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 th
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
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
q
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
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 th
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
r
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 ou
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 th
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
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.
>
>
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
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 abo
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 J
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 t
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
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 c
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
+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 sp
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
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
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 et
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 i
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 thi
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 QSslCertifi
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 o
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 app
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
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" t
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)?
>
&g
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
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
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 abo
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 so
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
>
>
>
> __
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 applicat
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 applica
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 ca
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
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 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-proj
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
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
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...
> - QD
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.
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 rea
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 includ
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
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 someth
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
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 t
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:
> He
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. C
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
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 do
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
>
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 w
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
>> generi
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
>>>
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
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-st
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
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
> implementatio
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 orde
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 QStr
71 matches
Mail list logo
