Qt-contributors-summit-2014-QtCS14QtNetwork: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Restore 2014 qtnetwork session notes)
m (Refined a category.)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:QtCS2014]]
[[Category:Developing Qt::Network]]
=CI problems=
=CI problems=


Line 28: Line 30:
=<span class="caps">SSL</span>=
=<span class="caps">SSL</span>=


* Rich hates the <span class="caps">SSL</span> errors <span class="caps">API</span>, the design is wrong, sometimes still requires a subeventloop, The concept of “accepting error” is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new <span class="caps">API</span>.
* Rich hates the <span class="caps">SSL</span> errors <span class="caps">API</span>, the design is wrong, sometimes still requires a subeventloop, The concept of "accepting error" is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new <span class="caps">API</span>.
* The new <span class="caps">API</span> would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current <span class="caps">API</span> leads to “overacceptance”, essentially to <span class="caps">SSL</span> errors.
* The new <span class="caps">API</span> would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current <span class="caps">API</span> leads to "overacceptance", essentially to <span class="caps">SSL</span> errors.
* Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear <span class="caps">API</span> that just needs to be hooked into Widgets/QML.
* Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear <span class="caps">API</span> that just needs to be hooked into Widgets/QML.



Latest revision as of 17:02, 6 January 2017

CI problems

  • Network tests fail a lot. Proposed solutions to avoid running network tests:
  • Move QtNetwork into its own git module
    • Thiago: Network cannot swapped out into its own module, due to dbus reqiring it in the future
  • Only run network tests when code affecting QtNetwork has changed -> more likely
  • Gurantees for VMs
  • CPU time
  • Swapping a problem?
  • Proposed Solution: Give more resources to VM tests. Frederik to take care.
  • Debugging of Network error causes:
    • Rich and Peter to sign NDA with Digia to get VPN access. Tuuka is involved, will start after holidays
  • CI resources are not well used, getting fixed in the future (Frederik)

SOCKS Proxy code

  • The code is horrible (Thiago)
  • We are not currently testing against SSH (the most common usecase probably), only Dante
  • The tests have been unstable, will be disabled for now
  • Rich volunteered to look into it at some point

NTLM

  • Tests are disabled
  • Before, we used Linux machines. Would be nice to also run against Windows Servers to get coverage for Domain credential use.
  • Digia would get a Windows Server VM up and running, danimo to provide instructions to Frederik

SSL

  • Rich hates the SSL errors API, the design is wrong, sometimes still requires a subeventloop, The concept of "accepting error" is wrong, you accept a chain. On top, there are different errors with different versions of OpenSSL. We need a new API.
  • The new API would be a lot simpler: Rubberstamp the chain, instead of individual errors. The current API leads to "overacceptance", essentially to SSL errors.
  • Possbilities for a predefined UI: No single UI will fit all purposes, but we can make it easier by providing a clear API that just needs to be hooked into Widgets/QML.

Qt 5.4 goals

  • Rich: QSslServer Class, in lieu of QTcpServer
  • Peter: Persistent Store: TLS session tickets, HSTS, Intermediate Certs,Cookies
  • iOS backend progressing well, would be nice to get in