Re: [Development] RFC: Managing the Addition of New SSL Backends
Thanks Richard for taking the time to write up your summary, as the subject is pretty vast. On 05/03/2014 11:23 PM, Richard Moore wrote: Support for QNAM It's obvious that to be useful, a backend must allow QNAM to make SSL requests. It need not support the more advanced features such as client certs, custom CAs, custom cipher suites etc. In order to handle user exceptions, we need a way to signal the errors. This means that QSslError would be required. Another option might be to offer some pre-built UI component for this, but that has the issue that a single component would probably not be a good fit to many UIs. Who is looking into WinRT, as I'd be interested in hearing what the WinRT API offers in terms of error reporting? On the iOS / Secure Transport front, QSslError support is not going to be as detailed as the OpenSSL backend as the API offers very little detail about what went wrong establishing a secure connection. 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. Can you explain your thinking in more detail on this point? For iOS / Secure Transport there is a clean separation between the SSL code and anything GUI related - to my knowledge there is no native dialog to handle accepting certificates. On the other hand: - you can get access to the raw DER data for the certificate (SecSecurityGetData [1]) - you can create a certificate instance from the raw DER data (SecCertificateCreateWithData [2]) I have therefore written some code to parse just enough ASN.1 to extract the certificate details: https://qt.gitorious.org/qt/sharkys-qtbase/source/ec189e6994b331e0e6662440a4a6fba3366277ec:src/network/ssl/qsslcertificate_ios.cpp Does WinRT provide access to the DER data? 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. I haven't looked into what iOS offers here yet. Cheers, Jeremy [1] https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCopyData [2] https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCreateWithData ___ 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
On 06/05/2014 08:11, Jeremy Lainé wrote: Thanks Richard for taking the time to write up your summary, as the subject is pretty vast. On 05/03/2014 11:23 PM, Richard Moore wrote: Support for QNAM It's obvious that to be useful, a backend must allow QNAM to make SSL requests. It need not support the more advanced features such as client certs, custom CAs, custom cipher suites etc. In order to handle user exceptions, we need a way to signal the errors. This means that QSslError would be required. Another option might be to offer some pre-built UI component for this, but that has the issue that a single component would probably not be a good fit to many UIs. Who is looking into WinRT, as I'd be interested in hearing what the WinRT API offers in terms of error reporting? As covered in in [1] there should be at least enough error reporting to implement a minimal SSL subset for WinRT. On the iOS / Secure Transport front, QSslError support is not going to be as detailed as the OpenSSL backend as the API offers very little detail about what went wrong establishing a secure connection. 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. Can you explain your thinking in more detail on this point? For iOS / Secure Transport there is a clean separation between the SSL code and anything GUI related - to my knowledge there is no native dialog to handle accepting certificates. I don't think that there is that kind of dialog for WinRT either or at least I haven't seen anything like that. So to have all that cross platform and not have to implement it again and again we should probably offer a Qt dialog which has the most important certificate properties inside? On the other hand: - you can get access to the raw DER data for the certificate (SecSecurityGetData [1]) - you can create a certificate instance from the raw DER data (SecCertificateCreateWithData [2]) I have therefore written some code to parse just enough ASN.1 to extract the certificate details: https://qt.gitorious.org/qt/sharkys-qtbase/source/ec189e6994b331e0e6662440a4a6fba3366277ec:src/network/ssl/qsslcertificate_ios.cpp Does WinRT provide access to the DER data? Yes see [2] 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. I haven't looked into what iOS offers here yet. Cheers, Jeremy [1] https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCopyData [2] https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecCertificateCreateWithData ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Cheers, Olli [1] https://bugreports.qt-project.org/browse/QTBUG-37497 [2] http://msdn.microsoft.com/en-us/library/windows/apps/windows.security.cryptography.certificates.certificate.getcertificateblob.aspx ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Jake Petroules as approver
The waiting period is over. I welcome Jake on the list of approvers. Jira and Gerrit modifications were done. -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org [development-bounces+alexander.blasche=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Tuesday, April 15, 2014 19:13 To: development@qt-project.org Subject: [Development] Nominating Jake Petroules as approver Hello I'd like to nominate Jake Petroules as approver. He's been very active in the Mac port in the recent months, helping out with issues like adding support for the CoreFoundation types in QtCore, among other tasks. He's located in the US West Coast, which helps me with reviews in late afternoons. Here's a link to his submissions https://codereview.qt-project.org/#q,owner:jake.petrou...@petroules.com,n,z Reviews: https://codereview.qt-project.org/#q,reviewer:jake.petrou...@petroules.com,n,z And dashboard: https://codereview.qt-project.org/#dashboard,1000530 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] Nominating Jake Petroules as approver
Thank you Alex! I'd also like to thank Thiago for the nomination and Jörg, Richard, Kurt, Christian, and Morten for their support. I promise to use my new privileges responsibly to continue to help develop and improve Qt (and qbs!). Long may they live. :) -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation On 2014-05-06, at 03:58 AM, Blasche Alexander alexander.blas...@digia.com wrote: The waiting period is over. I welcome Jake on the list of approvers. Jira and Gerrit modifications were done. -- Alex From: development-bounces+alexander.blasche=digia@qt-project.org [development-bounces+alexander.blasche=digia@qt-project.org] on behalf of Thiago Macieira [thiago.macie...@intel.com] Sent: Tuesday, April 15, 2014 19:13 To: development@qt-project.org Subject: [Development] Nominating Jake Petroules as approver Hello I'd like to nominate Jake Petroules as approver. He's been very active in the Mac port in the recent months, helping out with issues like adding support for the CoreFoundation types in QtCore, among other tasks. He's located in the US West Coast, which helps me with reviews in late afternoons. Here's a link to his submissions https://codereview.qt-project.org/#q,owner:jake.petrou...@petroules.com,n,z Reviews: https://codereview.qt-project.org/#q,reviewer:jake.petrou...@petroules.com,n,z And dashboard: https://codereview.qt-project.org/#dashboard,1000530 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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 ___ 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
[Development] Qt5.3 / Location Maps
Hi, i have been doing application that uses maps. Application UI is Qml but all data is generated on C++ side and once again, thee basic issue, is there any way to add items from C++ to Qml map. I used Qt4.8 and there was basically same issue, there was no way to add any C++ generated stuff on Qml map, no any way to add QGeoMapObject etc to Qml map. I resolved this issue by making own QML wrapper around QGraphicsGeoMap that accepts C++ classes. Then when i switched to Qt5.3, there was no maps at all, I ported Qt4.8 maps to Qt5.3 QtQuick1 and that works nicely. I also noticed that it can't be ported to QtQuick2 because old maps depend on QGraphicsView. Now I checked Qt5.3 location maps with qt3d . All fine, it copmpiles and run but alsp all C++ API is gone and there is still no way to add items from C++ to map. Even all QGeoMapObjects are gone. QDeclarativePolylineMapItem jas Path property that is type of QJSvalue and that looks only possible hook to c++, create path of polyline in C++ as QJSvalua and then pass this to Qml ? What is happening to Qt Maps C++ API ? There is still a lot of us that generate data displayed on map in C++ code and use Qml only for UI Kate ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating JIRA components relating to events.
Can we get a few volunteer default assignees for the components I suggested? GUI: Basic input methods QPA: xcb (X11) QPA: cocoa (OS X) QPA: windows Widget: Gesture support Em sex 25 abr 2014, às 17:27:23, Thiago Macieira escreveu: Hello I've just noticed that the GUI: Input methods component in JIRA has got an update now saying (Non-Latin languages). That is, it seems the purpose of that component has changed to mean complex input methods only. I've been reassigning to that component anything that is related to *any* input method, especially mouse, keyboard and touch, which bug reporters often submit to Core: Event System. Can I ask that we create a GUI: Basic Input Method (keyboard, mouse, touch) component? Does anyone feel like being the default assignee? Please reply in QTJIRA-258. I'd also like to ask that we create bug components for the main QPA platform plugins -- xcb, cocoa and windows -- since often we have bugs that are specific to those. I've filed request QTJIRA-256 for this, but we need default assignees. I'll also create a JIRA task to rename Core: Event System to Core: Event loop, hoping that fewer people report bugs related to creating events and consuming them against Core. Similarly, I'm asking that we move Core: Gesture support to Widget (QGestureManager is in QtWidget). [QTJIRA-255] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5.3 / Location Maps
Hi, On Tue, 6 May 2014 15:59:59 Kate Alhola wrote: Hi, i have been doing application that uses maps. Application UI is Qml but all data is generated on C++ side and once again, thee basic issue, is there any way to add items from C++ to Qml map. I used Qt4.8 and there was basically same issue, there was no way to add any C++ generated stuff on Qml map, no any way to add QGeoMapObject etc to Qml map. I resolved this issue by making own QML wrapper around QGraphicsGeoMap that accepts C++ classes. Then when i switched to Qt5.3, there was no maps at all, I ported Qt4.8 maps to Qt5.3 QtQuick1 and that works nicely. I also noticed that it can't be ported to QtQuick2 because old maps depend on QGraphicsView. Now I checked Qt5.3 location maps with qt3d . All fine, it copmpiles and run but alsp all C++ API is gone and there is still no way to add items from C++ to map. Even all QGeoMapObjects are gone. The Maps C++ API was removed from the public API during the initial porting to Qt5. This was done because we didn't want to be tied to a C++ API that we were not 100% satisfied with and to focus limited developer resources on the QtQuick2 implementation. For the time being the best way to place a large number of similar items on a map from C++ is to represent those items as a QAbstractListModel and use it as the source model for the MapItemView in QML. QDeclarativePolylineMapItem jas Path property that is type of QJSvalue and that looks only possible hook to c++, create path of polyline in C++ as QJSvalua and then pass this to Qml ? There is also the addCoordinate()/removeCoordinate() invokable functions which are easier to use than constructing a QJSValue, but probably less efficient if adding or removing a large number of coordinates. What sort of objects are you displaying on the map, is it just polylines? What is happening to Qt Maps C++ API ? There is still a lot of us that generate data displayed on map in C++ code and use Qml only for UI There is currently a lack of developer resources working on the location module. The good news is that recently the number of contributions to the location module has increased. Cheers, -- Aaron McCarthy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
