Re: [Interest] Need some help tracking down an issue

2023-04-14 Thread Mårten Nordheim via Interest 
Hey!

It's likely similar to the issue seen here:
https://bugreports.qt.io/browse/QTBUG-109511

Qt itself may use the global thread pool for certain parallelization, so if the
global thread-pool is fully occupied without letting any new tasks run
then you may experience some hanging.

Mårten


From: Interest  On Behalf Of Scott Bloom
Sent: fredag 14. april 2023 19:39
To: interest@qt-project.org
Subject: [Interest] Need some help tracking down an issue

I have an opensource project that is Qt based, to find duplicate files.  It 
started as a learning experience for working with thread pools.

Its pretty much 100% functional, however, I have issues where the GUI is 
non-responsive to user activity.

If anyone has the time, and willingness to do a code review with me, please let 
me know.  You can see the project at http://github.com/towel42-com/FindDupe

Thanks in advance,

Scott
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

2023-01-09 Thread Mårten Nordheim via Interest 
As Thiago mentioned, dynamically linking OpenSSL tends to be easier.
From what I can tell, the vcpkg directory should work with the 
FindOpenssl.cmake module.

You also may have trouble if you are mixing dynamically- and statically linked 
libraries!
Since they are likely linking the VC runtime in the same manner, they _cannot_ 
be mixed.
And, if I remember correctly, the default ‘static’ triplets in vcpkg all link 
the runtime statically.
Which means Qt and all other dependencies must also be built this way 
(-static-runtime for Qt).

You can also define your own triplet with dynamic lining of the VC runtime, but 
I’m not familiar with the process.

Mårten

From: Nuno Santos 
Sent: fredag 6. januar 2023 19:04
To: Mårten Nordheim 
Cc: Qt Interest ; Macieira, Thiago 

Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Marten,

I’m now trying to do the same in Windows but having problems.

I’m using vcpkg to build openssl and the only different in the configure line 
is the path to the installed vcpkgs


..\configure.bat -prefix C:\Qt\6.4.1\msvc2019_static -static -debug-and-release 
-nomake examples -nomake tests -nomake benchmarks -nomake manual-tests -nomake 
minimal-static-tests -openssl-linked -qtnamespace com_imaginando_qt_6_4_1 -- 
-DOPENSSL_ROOT_DIR="C:\vcpkg\installed\x64-windows-static\" 
-DOPENSSL_USE_STATIC_LIBS=TRUE

Inside C:\vcpkg\installed\x64-windows-static\include there is the openssl folder


And inside the C:\vcpkg\installed\x64-windows-static\lib there is:


libcrypto.lib
libeay32.lib
libssl.lib

However, the result is:

CMake Error at qtbase/cmake/QtBuildInformation.cmake:490 (message):
  Feature "openssl": Forcing to "ON" breaks its condition:  
QT_FEATURE_openssl_runtime OR QT_FEATURE_openssl_linked  Condition values dump: 
 QT_FEATURE_openssl_runtime = "OFF"
  QT_FEATURE_openssl_linked = "OFF"Call Stack (most recent call first):
  qtbase/cmake/QtFeature.cmake:281 (qt_configure_add_report_error)
  qtbase/cmake/QtFeature.cmake:403 (qt_feature_check_and_save_internal_value)
  qtbase/cmake/QtFeature.cmake:155 (qt_evaluate_feature)
  qtbase/cmake/QtFeature.cmake:349 (qt_evaluate_config_expression)
  qtbase/cmake/QtFeature.cmake:606 (qt_evaluate_feature)
  qtbase/cmake/QtFeature.cmake:575 (qt_feature_module_end)
  qtbase/src/CMakeLists.txt:9 (qt_feature_evaluate_features)


Trying to build without this, worked perfectly.

What am I missing here?

Thanks!

Nuno


On 8 Dec 2022, at 15:04, Nuno Santos 
mailto:nuno.san...@imaginando.pt>> wrote:

Marten,

I’ve noticed the nuance yesterday and tried but there was an error but I didn’t 
read the output correctly. I had a typo in a second define, 
OPENSSL_USE_STATIC_LIBS, which needed to be set to true. The following 
configure line worked:

./configure -prefix /Users/nsantos/Qt/6.4.1/macos_static -static 
-debug-and-release -nomake examples -nomake tests -nomake benchmarks -nomake 
manual-tests -nomake minimal-static-tests -openssl-linked -- 
-DOPENSSL_ROOT_DIR="/Users/nsantos/Qt-Utils/openssl" 
-DOPENSSL_USE_STATIC_LIBS=TRUE

Thiago, using openssl linked on Mac was a decision I have made a many years ago 
and I can’t remember the reason. Maybe it is not a good decision anymore. I 
know Apple has its SecureTransport framework. I might need to evaluate it again.

Thanks!

Regards,

Nuno


On 8 Dec 2022, at 08:49, Mårten Nordheim 
mailto:marten.nordh...@qt.io>> wrote:

The parameters to cmake (-D*) must be passed after a separating double dash 
(--).
 So, this:
-openssl-linked -DOPENSSL_ROOT_DIR="…"
 Should be like:
-openssl-linked -- -DOPENSSL_ROOT_DIR="…"
 Mårten
 From: Nuno Santos mailto:nuno.san...@imaginando.pt>>
Sent: onsdag 7. desember 2022 17:40
To: Mårten Nordheim mailto:marten.nordh...@qt.io>>
Cc: Qt Interest mailto:interest@qt-project.org>>
Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled
 Marten,
 Tried again without success. Maybe it's the directory layout. I don’t know I’m 
in the dark since the the CMakeOutput.log and CMakeError.log do not even 
mention ssl anywhere. Below is the new configure call:
 ./configure -prefix /Users/nsantos/Qt/6.4.2/macos -static -debug-and-release 
-nomake examples -nomake tests -nomake benchmarks -nomake manual-tests -nomake 
minimal-static-tests -openssl-linked 
-DOPENSSL_ROOT_DIR="/Users/nsantos/Qt-Utils/openssl" -DOPENSSL_USE_STATIC_LIBS
 Where:
 > find /Users/nsantos/Qt-Utils/openssl


gives:
 /Users/nsantos/Qt-Utils/openssl
/Users/nsantos/Qt-Utils/openssl/include
/Users/nsantos/Qt-Utils/openssl/include/crypto
/Users/nsantos/Qt-Utils/openssl/include/crypto/md32_common.h
…
/Users/nsantos/Qt-Utils/openssl/lib
/Users/nsantos/Qt-Utils/openssl/lib/libcrypto.a
/Users/nsantos/Qt-Utils/openssl/lib/libssl.a
 Where can I find more information?
 Thank you!
 Best regards,
 Nuno


On 7 Dec 2022, at 13:50, Mårten Nordheim

Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

2022-12-08 Thread Mårten Nordheim via Interest 
The parameters to cmake (-D*) must be passed after a separating double dash 
(--).

So, this:
-openssl-linked -DOPENSSL_ROOT_DIR="…"

Should be like:
-openssl-linked -- -DOPENSSL_ROOT_DIR="…"

Mårten

From: Nuno Santos 
Sent: onsdag 7. desember 2022 17:40
To: Mårten Nordheim 
Cc: Qt Interest 
Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Marten,

Tried again without success. Maybe it's the directory layout. I don’t know I’m 
in the dark since the the CMakeOutput.log and CMakeError.log do not even 
mention ssl anywhere. Below is the new configure call:

./configure -prefix /Users/nsantos/Qt/6.4.2/macos -static -debug-and-release 
-nomake examples -nomake tests -nomake benchmarks -nomake manual-tests -nomake 
minimal-static-tests -openssl-linked 
-DOPENSSL_ROOT_DIR="/Users/nsantos/Qt-Utils/openssl" -DOPENSSL_USE_STATIC_LIBS

Where:

> find /Users/nsantos/Qt-Utils/openssl


gives:

/Users/nsantos/Qt-Utils/openssl
/Users/nsantos/Qt-Utils/openssl/include
/Users/nsantos/Qt-Utils/openssl/include/crypto
/Users/nsantos/Qt-Utils/openssl/include/crypto/md32_common.h
…
/Users/nsantos/Qt-Utils/openssl/lib
/Users/nsantos/Qt-Utils/openssl/lib/libcrypto.a
/Users/nsantos/Qt-Utils/openssl/lib/libssl.a

Where can I find more information?

Thank you!

Best regards,

Nuno


On 7 Dec 2022, at 13:50, Mårten Nordheim 
mailto:marten.nordh...@qt.io>> wrote:

Ah, I don’t think OPENSSL_LIBS is in use anymore!
I think it was still left printed at the end of configure, I’m not sure the 
change removing it was merged into 6.4.
Please use the FindOpenSSL cmake find-module variables: 
https://cmake.org/cmake/help/latest/module/FindOpenSSL.html
In your case, passing -DOPENSSL_ROOT_DIR="/Users/nsantos/Qt-Utils/openssl"
at the end of your configure line, something like this:

./configure -prefix …. -openssl-linked -- -DOPENSSL_ROOT_DIR="…"

Mårten

From: Nuno Santos mailto:nuno.san...@imaginando.pt>>
Sent: onsdag 7. desember 2022 14:01
To: Mårten Nordheim mailto:marten.nordh...@qt.io>>
Cc: Qt Interest mailto:interest@qt-project.org>>
Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Marten,

Thank you for your reply.

Yes the patch required? My configure line was:

./configure -prefix /Users/nsantos/Qt/6.4.2/macos -static -debug-and-release 
-nomake examples -nomake tests -nomake benchmarks -nomake manual-tests -nomake 
minimal-static-tests -openssl-linked -I/Users/nsantos/Qt-Utils/openssl/include 
OPENSSL_LIBS="/Users/nsantos/Qt-Utils/openssl/lib/libssl.a 
/Users/nsantos/Qt-Utils/openssl/lib/libcrypto.a”

Best,

Nuno



On 7 Dec 2022, at 11:59, Mårten Nordheim 
mailto:marten.nordh...@qt.io>> wrote:

[Reply is inline]



-Original Message-
From: Nuno Santos mailto:nuno.san...@imaginando.pt>>
Sent: onsdag 7. desember 2022 11:50
To: Mårten Nordheim mailto:marten.nordh...@qt.io>>
Cc: Qt Interest mailto:interest@qt-project.org>>
Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Marten,

Thanks for your reply.

I’m on branch 6.4.2 and before any configure I always call:

git submodule foreach --recursive "git clean -dfx" && git clean -dfx

Should I try with another branch?

No, it shouldn't be needed. I just configured 6.4 branch locally and it
works fine. With only
https://codereview.qt-project.org/c/qt/qtbase/+/446542
as the extra patch.
I think this might indicate that the openssl compile test fails, which
could disable the feature. But just to make sure; do you call configure
like `../qt5/configure ... -openssl-linked` ?




Regards,

Nuno



On 7 Dec 2022, at 09:45, Mårten Nordheim 
mailto:marten.nordh...@qt.io>>
wrote:



Hey,

If this is a clean build I need to know which branch you are building.
If not then you could try deleting CMakeCache.txt and reconfiguring,
there were some changes around configuration of openssl recently
which may be conflicting with values in the cache.

Mårten



-Original Message-
From: Interest 
mailto:interest-boun...@qt-project.org>> On 
Behalf Of Nuno
Santos
Sent: onsdag 7. desember 2022 10:28
To: Qt Interest mailto:interest@qt-project.org>>
Subject: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Hi,

I’m trying to compile Qt 6 with openssl-linked but I’m having this error and
I’m not being able to interpret it.

What is failing? Can you please help me here?

Thanks in advance!

Regards,

Nuno


Configuring submodule 'qtbase'
CMake Error at qtbase/cmake/QtBuildInformation.cmake:490 (message):
Feature "openssl": Forcing to "ON" breaks its condition:

QT_FEATURE_openssl_runtime OR QT_FEATURE_openssl_linked

Condition values dump:

QT_FEATURE_openssl_runtime = "OFF"
QT_FEATURE_openssl_linked = "OFF"

Call Stack (most recent call first):
qtbase/cmake/QtFeature.cmake:281 (qt_configure

Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

2022-12-07 Thread Mårten Nordheim via Interest 
Ah, I don’t think OPENSSL_LIBS is in use anymore!
I think it was still left printed at the end of configure, I’m not sure the 
change removing it was merged into 6.4.
Please use the FindOpenSSL cmake find-module variables: 
https://cmake.org/cmake/help/latest/module/FindOpenSSL.html
In your case, passing -DOPENSSL_ROOT_DIR="/Users/nsantos/Qt-Utils/openssl"
at the end of your configure line, something like this:

./configure -prefix …. -openssl-linked -- -DOPENSSL_ROOT_DIR="…"

Mårten

From: Nuno Santos 
Sent: onsdag 7. desember 2022 14:01
To: Mårten Nordheim 
Cc: Qt Interest 
Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Marten,

Thank you for your reply.

Yes the patch required? My configure line was:

./configure -prefix /Users/nsantos/Qt/6.4.2/macos -static -debug-and-release 
-nomake examples -nomake tests -nomake benchmarks -nomake manual-tests -nomake 
minimal-static-tests -openssl-linked -I/Users/nsantos/Qt-Utils/openssl/include 
OPENSSL_LIBS="/Users/nsantos/Qt-Utils/openssl/lib/libssl.a 
/Users/nsantos/Qt-Utils/openssl/lib/libcrypto.a”

Best,

Nuno


On 7 Dec 2022, at 11:59, Mårten Nordheim 
mailto:marten.nordh...@qt.io>> wrote:

[Reply is inline]


-Original Message-
From: Nuno Santos mailto:nuno.san...@imaginando.pt>>
Sent: onsdag 7. desember 2022 11:50
To: Mårten Nordheim mailto:marten.nordh...@qt.io>>
Cc: Qt Interest mailto:interest@qt-project.org>>
Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Marten,

Thanks for your reply.

I’m on branch 6.4.2 and before any configure I always call:

git submodule foreach --recursive "git clean -dfx" && git clean -dfx

Should I try with another branch?

No, it shouldn't be needed. I just configured 6.4 branch locally and it
works fine. With only
https://codereview.qt-project.org/c/qt/qtbase/+/446542
as the extra patch.
I think this might indicate that the openssl compile test fails, which
could disable the feature. But just to make sure; do you call configure
like `../qt5/configure ... -openssl-linked` ?



Regards,

Nuno


On 7 Dec 2022, at 09:45, Mårten Nordheim 
mailto:marten.nordh...@qt.io>>
wrote:


Hey,

If this is a clean build I need to know which branch you are building.
If not then you could try deleting CMakeCache.txt and reconfiguring,
there were some changes around configuration of openssl recently
which may be conflicting with values in the cache.

Mårten


-Original Message-
From: Interest 
mailto:interest-boun...@qt-project.org>> On 
Behalf Of Nuno
Santos
Sent: onsdag 7. desember 2022 10:28
To: Qt Interest mailto:interest@qt-project.org>>
Subject: [Interest] Qt6 - Fails to compile when openssl-linked enabled

Hi,

I’m trying to compile Qt 6 with openssl-linked but I’m having this error and
I’m not being able to interpret it.

What is failing? Can you please help me here?

Thanks in advance!

Regards,

Nuno


Configuring submodule 'qtbase'
CMake Error at qtbase/cmake/QtBuildInformation.cmake:490 (message):
Feature "openssl": Forcing to "ON" breaks its condition:

QT_FEATURE_openssl_runtime OR QT_FEATURE_openssl_linked

Condition values dump:

QT_FEATURE_openssl_runtime = "OFF"
QT_FEATURE_openssl_linked = "OFF"

Call Stack (most recent call first):
qtbase/cmake/QtFeature.cmake:281 (qt_configure_add_report_error)
qtbase/cmake/QtFeature.cmake:403
(qt_feature_check_and_save_internal_value)
qtbase/cmake/QtFeature.cmake:155 (qt_evaluate_feature)
qtbase/cmake/QtFeature.cmake:349 (qt_evaluate_config_expression)
qtbase/cmake/QtFeature.cmake:606 (qt_evaluate_feature)
qtbase/cmake/QtFeature.cmake:575 (qt_feature_module_end)
qtbase/src/CMakeLists.txt:9 (qt_feature_evaluate_features)


-- Could NOT find md4c (missing: md4c_DIR)
-- Could NOT find md4c (missing: md4c_DIR)
CMake Error at qtbase/cmake/QtTargetHelpers.cmake:832 (message):
WrapOpenSSLHeaders::WrapOpenSSLHeaders is not a valid target.
Call Stack (most recent call first):
qtbase/src/plugins/tls/openssl/CMakeLists.txt:54
(qt_internal_add_target_include_dirs)


-- Configuring incomplete, errors occurred!
___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

2022-12-07 Thread Mårten Nordheim via Interest 
[Reply is inline]

> -Original Message-
> From: Nuno Santos 
> Sent: onsdag 7. desember 2022 11:50
> To: Mårten Nordheim 
> Cc: Qt Interest 
> Subject: Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled
> 
> Marten,
> 
> Thanks for your reply.
> 
> I’m on branch 6.4.2 and before any configure I always call:
> 
> git submodule foreach --recursive "git clean -dfx" && git clean -dfx
> 
> Should I try with another branch?

No, it shouldn't be needed. I just configured 6.4 branch locally and it
works fine. With only 
https://codereview.qt-project.org/c/qt/qtbase/+/446542
as the extra patch.
I think this might indicate that the openssl compile test fails, which
could disable the feature. But just to make sure; do you call configure
like `../qt5/configure ... -openssl-linked` ?

> 
> Regards,
> 
> Nuno
> 
> > On 7 Dec 2022, at 09:45, Mårten Nordheim 
> wrote:
> >
> > Hey,
> >
> > If this is a clean build I need to know which branch you are building.
> > If not then you could try deleting CMakeCache.txt and reconfiguring,
> > there were some changes around configuration of openssl recently
> > which may be conflicting with values in the cache.
> >
> > Mårten
> >
> >> -Original Message-
> >> From: Interest  On Behalf Of Nuno
> >> Santos
> >> Sent: onsdag 7. desember 2022 10:28
> >> To: Qt Interest 
> >> Subject: [Interest] Qt6 - Fails to compile when openssl-linked enabled
> >>
> >> Hi,
> >>
> >> I’m trying to compile Qt 6 with openssl-linked but I’m having this error 
> >> and
> >> I’m not being able to interpret it.
> >>
> >> What is failing? Can you please help me here?
> >>
> >> Thanks in advance!
> >>
> >> Regards,
> >>
> >> Nuno
> >>
> >>
> >> Configuring submodule 'qtbase'
> >> CMake Error at qtbase/cmake/QtBuildInformation.cmake:490 (message):
> >>  Feature "openssl": Forcing to "ON" breaks its condition:
> >>
> >>  QT_FEATURE_openssl_runtime OR QT_FEATURE_openssl_linked
> >>
> >>  Condition values dump:
> >>
> >>  QT_FEATURE_openssl_runtime = "OFF"
> >>  QT_FEATURE_openssl_linked = "OFF"
> >>
> >> Call Stack (most recent call first):
> >>  qtbase/cmake/QtFeature.cmake:281 (qt_configure_add_report_error)
> >>  qtbase/cmake/QtFeature.cmake:403
> >> (qt_feature_check_and_save_internal_value)
> >>  qtbase/cmake/QtFeature.cmake:155 (qt_evaluate_feature)
> >>  qtbase/cmake/QtFeature.cmake:349 (qt_evaluate_config_expression)
> >>  qtbase/cmake/QtFeature.cmake:606 (qt_evaluate_feature)
> >>  qtbase/cmake/QtFeature.cmake:575 (qt_feature_module_end)
> >>  qtbase/src/CMakeLists.txt:9 (qt_feature_evaluate_features)
> >>
> >>
> >> -- Could NOT find md4c (missing: md4c_DIR)
> >> -- Could NOT find md4c (missing: md4c_DIR)
> >> CMake Error at qtbase/cmake/QtTargetHelpers.cmake:832 (message):
> >>  WrapOpenSSLHeaders::WrapOpenSSLHeaders is not a valid target.
> >> Call Stack (most recent call first):
> >>  qtbase/src/plugins/tls/openssl/CMakeLists.txt:54
> >> (qt_internal_add_target_include_dirs)
> >>
> >>
> >> -- Configuring incomplete, errors occurred!
> >> ___
> >> Interest mailing list
> >> Interest@qt-project.org
> >> https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt6 - Fails to compile when openssl-linked enabled

2022-12-07 Thread Mårten Nordheim via Interest 
Hey,

If this is a clean build I need to know which branch you are building.
If not then you could try deleting CMakeCache.txt and reconfiguring,
there were some changes around configuration of openssl recently
which may be conflicting with values in the cache.

Mårten

> -Original Message-
> From: Interest  On Behalf Of Nuno
> Santos
> Sent: onsdag 7. desember 2022 10:28
> To: Qt Interest 
> Subject: [Interest] Qt6 - Fails to compile when openssl-linked enabled
> 
> Hi,
> 
> I’m trying to compile Qt 6 with openssl-linked but I’m having this error and
> I’m not being able to interpret it.
> 
> What is failing? Can you please help me here?
> 
> Thanks in advance!
> 
> Regards,
> 
> Nuno
> 
> 
> Configuring submodule 'qtbase'
> CMake Error at qtbase/cmake/QtBuildInformation.cmake:490 (message):
>   Feature "openssl": Forcing to "ON" breaks its condition:
> 
>   QT_FEATURE_openssl_runtime OR QT_FEATURE_openssl_linked
> 
>   Condition values dump:
> 
>   QT_FEATURE_openssl_runtime = "OFF"
>   QT_FEATURE_openssl_linked = "OFF"
> 
> Call Stack (most recent call first):
>   qtbase/cmake/QtFeature.cmake:281 (qt_configure_add_report_error)
>   qtbase/cmake/QtFeature.cmake:403
> (qt_feature_check_and_save_internal_value)
>   qtbase/cmake/QtFeature.cmake:155 (qt_evaluate_feature)
>   qtbase/cmake/QtFeature.cmake:349 (qt_evaluate_config_expression)
>   qtbase/cmake/QtFeature.cmake:606 (qt_evaluate_feature)
>   qtbase/cmake/QtFeature.cmake:575 (qt_feature_module_end)
>   qtbase/src/CMakeLists.txt:9 (qt_feature_evaluate_features)
> 
> 
> -- Could NOT find md4c (missing: md4c_DIR)
> -- Could NOT find md4c (missing: md4c_DIR)
> CMake Error at qtbase/cmake/QtTargetHelpers.cmake:832 (message):
>   WrapOpenSSLHeaders::WrapOpenSSLHeaders is not a valid target.
> Call Stack (most recent call first):
>   qtbase/src/plugins/tls/openssl/CMakeLists.txt:54
> (qt_internal_add_target_include_dirs)
> 
> 
> -- Configuring incomplete, errors occurred!
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QWebSocketServer on iOS

2022-03-29 Thread Mårten Nordheim 
Hey Alex,

Unfortunately I don't think there's a way around it as it's a security measure 
(though I could be wrong).
It simply disallows establishing insecure connections from secure sources.

Mårten.


From: Interest  on behalf of Alexander Carôt 

Sent: Tuesday, March 29, 2022 09:37
To: qt qt
Subject: Re: [Interest] QWebSocketServer on iOS

>> Can you confirm and possibly resolve ?

I just created a secure websocket on localhost and it connected fine. Looks 
like iOS does not permit non-secure websockets on secure websites at all (on 
OSX this works except for Safari). If there is another workaround please let me 
know.

Best

Alex


--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797


> Gesendet: Montag, 28. März 2022 um 19:41 Uhr
> Von: "Alexander Carôt" 
> An: "Mårten Nordheim" 
> Cc: "qt qt" 
> Betreff: Re: [Interest] QWebSocketServer on iOS
>
> Hej Marten,
>
> Here we go – please find the sample code regarding the iOS websocket issue 
> here:
>
> https://www.dropbox.com/s/y7nr3ywht75exhw/iOS_audio.zip?dl=0
>
> This one does not contain the webbrowser yet it can be used with any iOS 
> browser (Safari, Chrome, FF etc.) with the following script:
>
> http://carot.de
>
> If successful it shows "SJC connected – version 211105".
>
> I think I already figured when it fails: If the script runs on an ssl 
> encypted site it does not connect – on OSX this only happens with Safari but 
> on iOS this might be a general networking restriction. Here is the same 
> script on a secure website:
>
> https://soundjack.eu/ws
>
> Can you confirm and possibly resolve ?
>
> Thanks and best
>
> Alex
>
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
>
>
> > Gesendet: Montag, 28. März 2022 um 10:02 Uhr
> > Von: "Mårten Nordheim" 
> > An: "Alexander Carôt" , "qt qt" 
> > 
> > Betreff: Re: Re: Re: [Interest] QWebSocketServer on iOS
> >
> > Is there anything printed out in the console of the browser?
> > And it shouldn't be needed, but you can try connecting to the
> > originAuthenticationRequired signal:
> > https://doc.qt.io/qt-5/qwebsocketserver.html#originAuthenticationRequired
> > In case that's where it somehow goes wrong.
> >
> > Mårten
> >
> > 
> > From: Alexander Carôt 
> > Sent: Friday, March 25, 2022 20:39
> > To: Mårten Nordheim; qt qt
> > Subject: Aw: Re: Re: [Interest] QWebSocketServer on iOS
> >
> > Hej Marten,
> >
> > >> Just on the off-chance that it makes a difference - have you tried using 
> > >> ws://localhost instead of 127.0.0.1?
> >
> > Just did it a few hours ago and it made no difference.
> >
> > >> If not, do you have a minimal reproducer that can be shared 
> > >> (with/without the qml browser)?
> >
> > I will send over sample code which includes the problematic sources in the 
> > most illustrative way soon.
> >
> > Meantime here more insights to the issue:
> >
> > I reconfigured the websocket server to 0.0.0.0 – then I can connect from 
> > the same LAN from a different machine via a script that contains 
> > ws://192.168.0.56:50050, however, I cannot connect from an external Domain 
> > myDomain.de/connectScript.html (the same script and call above is triggered 
> > on the same machine in the same LAN, however, now retrieved from a remote 
> > server). Neither I can connect from the iOS app-own browser via localhost 
> > either. Furthermore, please forget about the crash which occurs for other 
> > implementational reasons.
> >
> > Will get back with sample code,
> > best
> >
> > Alex
> >
> >
> > --
> > http://www.carot.de
> > Email : alexan...@carot.de
> > Tel.: +49 (0)177 5719797
> >
> >
> > > Gesendet: Freitag, 25. März 2022 um 11:54 Uhr
> > > Von: "Mårten Nordheim" 
> > > An: "Alexander Carôt" , "qt qt" 
> > > 
> > > Betreff: Re: Re: [Interest] QWebSocketServer on iOS
> > >
> > > Hey again,
> > >
> > > Just on the off-chance that it makes a difference - have you tried using 
> > > ws://localhost instead of 127.0.0.1?
> > > If not, do you have a minimal reproducer that can be shared (with/without 
> > > the qml browser)?
> > >
> > > Mårten.
> > >
> > > 
> > > From: Alexander Carôt 
&

Re: [Interest] QWebSocketServer on iOS

2022-03-28 Thread Mårten Nordheim 
Is there anything printed out in the console of the browser?
And it shouldn't be needed, but you can try connecting to the
originAuthenticationRequired signal:
https://doc.qt.io/qt-5/qwebsocketserver.html#originAuthenticationRequired
In case that's where it somehow goes wrong.

Mårten


From: Alexander Carôt 
Sent: Friday, March 25, 2022 20:39
To: Mårten Nordheim; qt qt
Subject: Aw: Re: Re: [Interest] QWebSocketServer on iOS

Hej Marten,

>> Just on the off-chance that it makes a difference - have you tried using 
>> ws://localhost instead of 127.0.0.1?

Just did it a few hours ago and it made no difference.

>> If not, do you have a minimal reproducer that can be shared (with/without 
>> the qml browser)?

I will send over sample code which includes the problematic sources in the most 
illustrative way soon.

Meantime here more insights to the issue:

I reconfigured the websocket server to 0.0.0.0 – then I can connect from the 
same LAN from a different machine via a script that contains 
ws://192.168.0.56:50050, however, I cannot connect from an external Domain 
myDomain.de/connectScript.html (the same script and call above is triggered on 
the same machine in the same LAN, however, now retrieved from a remote server). 
Neither I can connect from the iOS app-own browser via localhost either. 
Furthermore, please forget about the crash which occurs for other 
implementational reasons.

Will get back with sample code,
best

Alex


--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797


> Gesendet: Freitag, 25. März 2022 um 11:54 Uhr
> Von: "Mårten Nordheim" 
> An: "Alexander Carôt" , "qt qt" 
> 
> Betreff: Re: Re: [Interest] QWebSocketServer on iOS
>
> Hey again,
>
> Just on the off-chance that it makes a difference - have you tried using 
> ws://localhost instead of 127.0.0.1?
> If not, do you have a minimal reproducer that can be shared (with/without the 
> qml browser)?
>
> Mårten.
>
> ____
> From: Alexander Carôt 
> Sent: Thursday, March 24, 2022 17:51
> To: Mårten Nordheim; qt qt
> Subject: Aw: Re: [Interest] QWebSocketServer on iOS
>
> Hej Marten and all,
>
> >>though on mobile devices you may be subject to your application
> >> being put to sleep when it goes into the background.
>
> Meantime this is what I ran into which is why I eventually bundled the qml 
> minibrowser and my application. The browser tries to connect to the 
> application via ws://127.0.0.1:50050 and this works out well on macOS. On 
> iOS, however, the connection fails and, furthermore, any other action (e.g. 
> sending packets) with the websocket server endpoint makes the app crash. 
> Hence, I'd suspect this is due to iOS specific security settings – also 
> because the dialog to allow local network usage does not show up. Please find 
> here the list of network related security keys I applied in the Info.plist 
> file
>
> NSLocalNetworkUsageDescription
> Uses local networking to communicate settings…
> NSTemporaryExceptionAllowsInsecureHTTPLoads
>
> NSAppTransportSecurity
>
> NSAllowsArbitraryLoads
> NSAllowsArbitraryLoadsForMedia
> NSAllowsArbitraryLoadsInWebContent
> NSAllowsLocalNetworking
> NSExceptionDomains
> 
> localhost
> 
> 
> NSExceptionAllowsInsecureHTTPLoads
> NSIncludesSubdomains
> 
> mydomain.com
> 
> 
> NSExceptionAllowsInsecureHTTPLoads
> NSIncludesSubdomains
> 
> 
> 
>
> Am I missing anything in terms of security keys or does anyone have a 
> different suggestions how to resolve this issue ?
>
> Best
>
> Alex
>
> P.S.: Thiago: No firewalls installed and the websocket is running on 
> localhost.
>
>
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
>
>
> > Gesendet: Dienstag, 22. März 2022 um 12:43 Uhr
> > Von: "Mårten Nordheim" 
> > An: "Alexander Carôt" , "qt qt" 
> > 
> > Betreff: Re: [Interest] QWebSocketServer on iOS
> >
> > Hello Alex,
> >
> > There's no reason why listening to a port on iOS shouldn't work, though on 
> > mobile devices you may be subject to your application
> > being put to sleep when it goes into the background.
> >
> > Mårten.
> >
> > ___

Re: [Interest] QWebSocketServer on iOS

2022-03-25 Thread Mårten Nordheim 
Hey again,

Just on the off-chance that it makes a difference - have you tried using 
ws://localhost instead of 127.0.0.1?
If not, do you have a minimal reproducer that can be shared (with/without the 
qml browser)?

Mårten.


From: Alexander Carôt 
Sent: Thursday, March 24, 2022 17:51
To: Mårten Nordheim; qt qt
Subject: Aw: Re: [Interest] QWebSocketServer on iOS

Hej Marten and all,

>>though on mobile devices you may be subject to your application
>> being put to sleep when it goes into the background.

Meantime this is what I ran into which is why I eventually bundled the qml 
minibrowser and my application. The browser tries to connect to the application 
via ws://127.0.0.1:50050 and this works out well on macOS. On iOS, however, the 
connection fails and, furthermore, any other action (e.g. sending packets) with 
the websocket server endpoint makes the app crash. Hence, I'd suspect this is 
due to iOS specific security settings – also because the dialog to allow local 
network usage does not show up. Please find here the list of network related 
security keys I applied in the Info.plist file

NSLocalNetworkUsageDescription
Uses local networking to communicate settings…
NSTemporaryExceptionAllowsInsecureHTTPLoads

NSAppTransportSecurity
   
NSAllowsArbitraryLoads
NSAllowsArbitraryLoadsForMedia
NSAllowsArbitraryLoadsInWebContent
NSAllowsLocalNetworking
NSExceptionDomains

localhost


NSExceptionAllowsInsecureHTTPLoads
NSIncludesSubdomains

mydomain.com


NSExceptionAllowsInsecureHTTPLoads
NSIncludesSubdomains




Am I missing anything in terms of security keys or does anyone have a different 
suggestions how to resolve this issue ?

Best

Alex

P.S.: Thiago: No firewalls installed and the websocket is running on localhost.


--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797


> Gesendet: Dienstag, 22. März 2022 um 12:43 Uhr
> Von: "Mårten Nordheim" 
> An: "Alexander Carôt" , "qt qt" 
> 
> Betreff: Re: [Interest] QWebSocketServer on iOS
>
> Hello Alex,
>
> There's no reason why listening to a port on iOS shouldn't work, though on 
> mobile devices you may be subject to your application
> being put to sleep when it goes into the background.
>
> Mårten.
>
> 
> From: Interest  on behalf of Alexander Carôt 
> 
> Sent: Monday, March 21, 2022 10:24
> To: qt qt
> Subject: [Interest] QWebSocketServer on iOS
>
> Hi all,
>
> I have an application running a QWebSocketServer::NonSecureMode on localhost 
> and I am using a web browser to connect. This works fine on OSX, Linux and 
> Windows so far.
>
> However, I just ported the app to iOS and here it has so far not been 
> possible to establish a connection yet.
>
> Before I dig deeper in terms of debugging I wonder if probably this not 
> supported for iOS at all ?
>
> So far I did not see any error message, however.
>
> Thanks in advance for pointers of any kind.
>
> Best
>
> Alex
>
> --
> http://www.carot.de
> Email : alexan...@carot.de
> Tel.: +49 (0)177 5719797
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QWebSocketServer on iOS

2022-03-22 Thread Mårten Nordheim 
Hello Alex,

There's no reason why listening to a port on iOS shouldn't work, though on 
mobile devices you may be subject to your application
being put to sleep when it goes into the background.

Mårten.


From: Interest  on behalf of Alexander Carôt 

Sent: Monday, March 21, 2022 10:24
To: qt qt
Subject: [Interest] QWebSocketServer on iOS

Hi all,

I have an application running a QWebSocketServer::NonSecureMode on localhost 
and I am using a web browser to connect. This works fine on OSX, Linux and 
Windows so far.

However, I just ported the app to iOS and here it has so far not been possible 
to establish a connection yet.

Before I dig deeper in terms of debugging I wonder if probably this not 
supported for iOS at all ?

So far I did not see any error message, however.

Thanks in advance for pointers of any kind.

Best

Alex

--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Qt6: Android: checkPermission is not available yet?

2021-09-18 Thread Mårten Nordheim 
Hello!

Did you add core-private (/ CorePrivate) to your dependencies?
It might print a warning when you do, though in this case it's to be expected.

Mårten


From: Interest  on behalf of Alexander 
Dyagilev 
Sent: Saturday, September 18, 2021 18:24
To: interest@qt-project.org
Subject: [Interest] Qt6: Android: checkPermission is not available yet?

Hello guys :)

I'm wondering that is the equivalent for this function:

bool checkPermission()
{
 static const QString
PERMISSION("android.permission.WRITE_EXTERNAL_STORAGE");
 QtAndroid::PermissionResult r = QtAndroid::checkPermission(PERMISSION);
 if (r == QtAndroid::PermissionResult::Denied)
 {
 QtAndroid::requestPermissionsSync(QStringList() << PERMISSION);
 r = QtAndroid::checkPermission(PERMISSION);
 if (r == QtAndroid::PermissionResult::Denied)
 return false;
 }
 return true;
}

It seems it does not exist?

I've tried this (Qt 6.2 RC):

#include 
QtAndroidPrivate::checkPermission(QtAndroidPrivate::Storage);

It can't be compiled due to the following error: fatal error:
'QtCore/private/qglobal_p.h' file not found

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Missing QMap Algebra?

2021-03-23 Thread Mårten Nordheim 
Hello!

QMap::insert(const QMap &) was added in 5.15. No operator+ though.

https://doc.qt.io/qt-5/qmap.html#insert-2


From: Interest  on behalf of Jason H 

Sent: Tuesday, March 23, 2021 14:52
To: interestqt-project.org
Subject: [Interest] Missing QMap Algebra?

I've been in the python world lately and python has a dict.update() 
https://python-reference.readthedocs.io/en/latest/docs/dict/update.html
It seems that QMap has no such function anymore, but it also never did? unite() 
would make a QMultiMap, so there would be multiple entries rather than one. 
Which has me asking the question, do I have to provide this myself? Seems a 
pretty trivial thing to have to provide?

QVariantMap map_a, map_b;
...
auto combined_map = map_a;
for (const QString& key: map_b.keys()) {
combined_map[key] = map_b[key];
}

Additionally there is no + operator for it, which is actually what I want:

combined_map = map_a + map_b;

But I would be happy with:

   combined_map.update(map_b);


Additionally if we're trying to provide as much algebra as possible:

map_a = combined_map - map_b.keys() // remove by matching key
map_a = combined_map - map_b;   // remove by matching key-value pairs

In Python, these are doable in a 1-line list/dict comprehension.

Thoughts?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash in Qt OpenSSL thread

2021-03-23 Thread Mårten Nordheim 
Hello!

Given the issue (heap corruption) and lack of symbols for openssl it's somewhat 
hard to determine.
With heap corruption it could be a buffer overflow somewhere else in the 
application which is then caught during the malloc call.

Mårten


From: Interest  on behalf of Alexander 
Dyagilev 
Sent: Sunday, March 21, 2021 20:32
To: Interests Qt
Subject: [Interest] Crash in Qt OpenSSL thread

Hello,

One of our users reported the following crash:

Unhandled exception at 0x7FF82C50EF89 (ntdll.dll) in
fdm.exe.3964.dmp: 0xC374: A heap has been corrupted (parameters:
0x7FF82C5777F0).

With the following stack trace:

ntdll.dll!RtlReportFatalFailure()Unknown
ntdll.dll!RtlReportCriticalFailure()Unknown
ntdll.dll!RtlpHeapHandleError()Unknown
ntdll.dll!RtlpHpHeapHandleError()Unknown
ntdll.dll!RtlpLogHeapFailure()Unknown
ntdll.dll!RtlpLowFragHeapAllocFromContext()Unknown
ntdll.dll!RtlpAllocateHeapInternal()Unknown
ucrtbase.dll!_malloc_base()Unknown
libcrypto-1_1-x64.dll!7fffc4a6f16e()Unknown
libcrypto-1_1-x64.dll!7fffc4a719b9()Unknown
libssl-1_1-x64.dll!7ff813f6e166()Unknown
libssl-1_1-x64.dll!7ff813f85f3f()Unknown
libssl-1_1-x64.dll!7ff813f66d0c()Unknown
Qt5Network.dll!QSslSocketBackendPrivate::startHandshake() Line 1011C++
Qt5Network.dll!QSslSocketBackendPrivate::startServerEncryption() Line
695C++
Qt5Network.dll!QSslSocket::startClientEncryption() Line 1855 C++
Qt5Network.dll!QSslSocket::qt_static_metacall(QObject * _o,
QMetaObject::Call _c, int _id, void * * _a) Line 180C++
Qt5Core.dll!QMetaObject::activate(QObject * sender, int signalOffset,
int local_signal_index, void * * argv) Line 3807 C++
Qt5Network.dll!QAbstractSocketPrivate::_q_testConnection() Line 1181C++
Qt5Network.dll!QWriteNotifier::event(QEvent * e) Line 1310C++
Qt5Widgets.dll!QApplicationPrivate::notify_helper(QObject * receiver,
QEvent * e) Line 3652C++
Qt5Widgets.dll!QApplication::notify(QObject * receiver, QEvent * e) Line
3604C++
Qt5Core.dll!QCoreApplication::notifyInternal2(QObject * receiver, QEvent
* event) Line 1088C++
Qt5Core.dll!qt_internal_proc(HWND__ * hwnd, unsigned int message,
unsigned __int64 wp, __int64 lp) Line 204C++
user32.dll!UserCallWinProcCheckWow()Unknown
user32.dll!DispatchMessageWorker()Unknown
Qt5Core.dll!QEventDispatcherWin32::processEvents(QFlags flags) Line 650C++
Qt5Core.dll!QEventLoop::exec(QFlags
flags) Line 225C++
Qt5Core.dll!QThread::exec() Line 531C++
Qt5Core.dll!QThreadPrivate::start(void * arg) Line 405C++
kernel32.dll!BaseThreadInitThunk()Unknown
ntdll.dll!RtlUserThreadStart()Unknown

We use Qt 5.12.10. It seems it's a rare crash. Any thoughts what can be
the cause of it and can it be fixed somehow?

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] wss:// on localhost

2020-08-04 Thread Mårten Nordheim 
Sure! ws://[::1] also worked for me.

Mårten


From: Interest  on behalf of Thiago Macieira 

Sent: Tuesday, August 4, 2020 18:21
To: interest@qt-project.org
Subject: Re: [Interest] wss:// on localhost

On Tuesday, 4 August 2020 07:44:06 PDT Mårten Nordheim wrote:
> Ah sorry. What I meant is that I had a secure website
> (https://myothercomputer/app.html) which initiated a websocket connection
> to ws://127.0.0.1, and it works fine. You have to use "127.0.0.1" in this
> case and not "localhost" due to the fact that you can remove or change what
> "localhost" should point to.

Can you test ws://[::1]/ ?

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] wss:// on localhost

2020-08-04 Thread Mårten Nordheim 
Ah sorry. What I meant is that I had a secure website 
(https://myothercomputer/app.html) which initiated a websocket connection to 
ws://127.0.0.1, and it works fine.
You have to use "127.0.0.1" in this case and not "localhost" due to the fact 
that you can remove or change what "localhost" should point to.

Mårten


From: Alexander Carôt 
Sent: Tuesday, August 4, 2020 15:04
To: Mårten Nordheim
Cc: Thiago Macieira; interest@qt-project.org
Subject: Aw: Re: [Interest] wss:// on localhost

Hi Marten,

>> Looking at https://letsencrypt.org/docs/certificates-for-localhost/ they 
>> mention that "modern" browsers let you make insecure connections to
>>127.0.0.1.
>> Tested locally with a secure website connecting to ws://127.0.0.1 and it 
>> works fine. Which browsers do or don't support it I'm not sure though,
>>but it could be enough for your use-case?

ws on 127.0.0.1 is not the problem. The problem is *mixed content* with ws on 
localhost: Almost any up2date CMS or web use case in general requires me to 
apply SSL (https) and I cannot run an unsecure websocket from a secure site. 
This sounds like a trivial problem but in practice this leads to my conclusion 
below.

Best

Alex

--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797


> Gesendet: Dienstag, 04. August 2020 um 10:00 Uhr
> Von: "Mårten Nordheim" 
> An: "Alexander Carôt" 
> Cc: "Thiago Macieira" , "interest@qt-project.org" 
> 
> Betreff: Re: [Interest] wss:// on localhost
>
> Looking at https://letsencrypt.org/docs/certificates-for-localhost/ they 
> mention that "modern" browsers let you make insecure connections to 127.0.0.1.
> Tested locally with a secure website connecting to ws://127.0.0.1 and it 
> works fine. Which browsers do or don't support it I'm not sure though, but it 
> could be enough for your use-case?
>
> Mårten
>
> 
> From: Interest  on behalf of Alexander Carôt 
> 
> Sent: Tuesday, August 4, 2020 09:51
> To: Alexander Carôt
> Cc: Thiago Macieira; interest@qt-project.org
> Subject: Re: [Interest] wss:// on localhost
>
> >> A conventional html page (classical web browser) launches a websocket via 
> >> wss://localhost:1234 and connects to a Qt
> >application which hosts a QtWebsocket Server which binds to localhost:1234. 
> >This way I achieve communication between browser
> >>and app. Would love to stay with ws:// but modern CMS (well - websites in 
> >>general) etc. require using SSL and mixed content is
> >>not working anymore.
>
> 1) For now I do accept that wss://localhost:wxyz is not possible because
>
> 2) I identified a workaround: Rather than a websocket I create a UDP socket 
> on localhost and choose WebRTC within the browser in order to send UDP 
> messages.
>
> 3) Is it worth doing further discussion about wss://localhost.abcd or do we 
> have to accept also in the long term ? It would be a shame because it's such 
> a convenient solution.
>
> 4) It's also a shame how the Internet has become - I still have a mindset of 
> the year 2000 where the web was not really a significant resource of criminal 
> intent. I understand this can lead to misunderstanding ;-)
>
> 5) Thanks for all the comments - I actually learnt a lot regarding security !
>
>
> Best
>
> Alex
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] wss:// on localhost

2020-08-04 Thread Mårten Nordheim 
Looking at https://letsencrypt.org/docs/certificates-for-localhost/ they 
mention that "modern" browsers let you make insecure connections to 127.0.0.1.
Tested locally with a secure website connecting to ws://127.0.0.1 and it works 
fine. Which browsers do or don't support it I'm not sure though, but it could 
be enough for your use-case?

Mårten


From: Interest  on behalf of Alexander Carôt 

Sent: Tuesday, August 4, 2020 09:51
To: Alexander Carôt
Cc: Thiago Macieira; interest@qt-project.org
Subject: Re: [Interest] wss:// on localhost

>> A conventional html page (classical web browser) launches a websocket via 
>> wss://localhost:1234 and connects to a Qt
>application which hosts a QtWebsocket Server which binds to localhost:1234. 
>This way I achieve communication between browser
>>and app. Would love to stay with ws:// but modern CMS (well - websites in 
>>general) etc. require using SSL and mixed content is
>>not working anymore.

1) For now I do accept that wss://localhost:wxyz is not possible because

2) I identified a workaround: Rather than a websocket I create a UDP socket on 
localhost and choose WebRTC within the browser in order to send UDP messages.

3) Is it worth doing further discussion about wss://localhost.abcd or do we 
have to accept also in the long term ? It would be a shame because it's such a 
convenient solution.

4) It's also a shame how the Internet has become - I still have a mindset of 
the year 2000 where the web was not really a significant resource of criminal 
intent. I understand this can lead to misunderstanding ;-)

5) Thanks for all the comments - I actually learnt a lot regarding security !


Best

Alex
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] wss:// on localhost

2020-07-27 Thread Mårten Nordheim 
Hello Alexander,

I don't know (or recall) what your setup is like. The following answer assumes 
the website you refer to also runs on the local machine:

Somewhat going in the other direction I'd say wss/https is not necessary if 
your application actually only listens to localhost (127.0.0.1/[::1]).
It won't travel across the network at that point, and if the local machine is 
compromised encryption doesn't matter much.

If you are listening to other addresses as well though (to let other clients in 
the network connect as well) then you need to generate certificates
that includes the hostname or IP of the machine running the server since 
"localhost" is no longer enough/correct for that.

However if the website is remote and you run attempt to connect to a websocket 
on the local machine then it needs to be encrypted and Thiago's
suggestion will get you most of the way. You will also need to get the OS to 
trust the certificate for the browser to accept it as well. Usually with
untrusted certificates browsers will show a warning and let you ignore it, but 
that doesn't happen in most browsers when opening a websocket
connection in the background!

Mårten


From: Interest  on behalf of Alexander Carôt 

Sent: Tuesday, July 21, 2020 19:32
To: Thiago Macieira
Cc: Paul Pfützenreuter; interest@qt-project.org
Subject: Re: [Interest] wss:// on localhost

Hej Thiago,

> Whether they work or not is irrelevant, since you shouldn't be shipping the
> same certificate to all users. You'd have to make it extremely long-lived
> (expiry 20 years from now). Generating a short-lived one (3 months) limits the
> damage if it somehow gets misused.


just to avoid misunderstandings: The goal is not sending existing certificates 
as part of the application download but rather generate the certificte 
automatically upon launching the app ?


> There are lots of examples on the Internet on how to do this with the openssl
> command. You'll have to find out how to do it with the API, if you don't want
> to ship the command.


If my assumption above is right then any kind of automized process would be 
fine to me - e.g. running the openssl command as part of a script, which is 
executed before launching the application or probably generate the certificate 
within the app code which would be even more convenient.

Is this somehow the right track or am I completely mistaken ? Sorry again - 
completely new in the domain of security ;-)

Best

Alex









> 1) create a private/public key pair (usually RSA, but doesn't need to be).
> Creating a private key usually involves random number, so please be sure that
> OpenSSL's random generator is properly seeded, if it can't be guaranteed to
> auto-seed. Qt's QRandomGenerator::system() is of cryptographic quality and
> requires no seeding[*], so you can use it to generate random data to seed
> OpenSSL if necessary. RSA key pairs are usually big these days (2048 to 4096
> bits), so you may want to investigate an elliptic curve key instead, which
> would reduce the computation time.
>
> 2) create a certificate-signing request (CSR), which contains the certificate
> header fields. Notably, it has the CN (Common Name) field, which identifies
> which hostnames it applies for. You want "localhost"
>
> 3) sign the CSR. You'll sign with the key used in #1, causing this to be self-
> signed. The result is the certificate.
>
> There are lots of examples on the Internet on how to do this with the openssl
> command. You'll have to find out how to do it with the API, if you don't want
> to ship the command.
>
> For anyone wondering about turning off the SSL error on self-signed
> certificates: self-signing isn't inherently bad. The SSL error comes not
> because the certificate is self-signed, but because it's not signed by any
> certificate in the Certificate Authority list. The fact it's self-signed is
> simply extra information, as it's the most common cause of an authority not
> being found. But if you add the certificate itself to the CA list (in fact,
> make it the only entry!), then it'll match to a CA and you get no SSL error.
>
> [*] this is also why René is having problems with the RDRAND instruction in
> the other thread.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel DPG Cloud Engineering
>
>
>
> ___
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QWebSocket limit connection

2020-05-11 Thread Mårten Nordheim 
Hello!

If you are using a QWebSocketServer you can call close() when a new connection 
has been established and call listen() again when the currently-connected 
socket disconnects.

Attached is a toy example of doing so.

Mårten

PS: Apologies for double mail to Alexander, pressed Reply instead of Reply 
all...


From: Interest  on behalf of "Alexander Carôt" 

Sent: Monday, May 11, 2020 10:13
To: qt qt
Subject: [Interest] QWebSocket limit connection

Hello all,

I am using a QWebSocket in order to communicate between a browser and an 
application which works fine.

In my specific use case I want to prevent more than one browser to connect to 
the application.

Is there a way to decline further connections after one has been established ?

Thanks in advance,
best

Alex


--
http://www.carot.de
Email : alexan...@carot.de
Tel.: +49 (0)177 5719797

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
#include 
#include 
#include 
#include 

int main(int argc, char **argv)
{
QCoreApplication app(argc, argv);

QWebSocketServer server("hi", QWebSocketServer::NonSecureMode);
server.setMaxPendingConnections(1);
server.listen(QHostAddress::Any, 24242);
QObject::connect(, ::newConnection, []() {
QWebSocket *socket = server.nextPendingConnection();

QObject::connect(socket, ::textMessageReceived, [](const 
QString ) {
qDebug() << message;
});

QObject::connect(socket, ::disconnected, []() {
server.listen(QHostAddress::Any, 24242);
});

server.close();
});

return app.exec();
}
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] QSslCertificate verify unimplemented on iOS ?

2020-02-28 Thread Mårten Nordheim 
Yes, it’s not implemented. Not 100% sure on the details but I believe there’s 
some missing API, so it hasn’t been seen as feasible to implement.
https://github.com/qt/qtbase/blob/5.15/src/network/ssl/qsslsocket_mac.cpp#L629

Now Secure transport is “considered legacy” from Apple’s side. What this means 
is not certain, but we’re probably not getting new API :(
https://developer.apple.com/documentation/security/secure_transport

Mårten

From: ekke
Sent: fredag 28. februar 2020 09:26
To: interest@qt-project.org
Subject: [Interest] QSslCertificate verify unimplemented on iOS ?


I'm using QSslCertificate::verify successfully on Android

QListhttps://doc.qt.io/qt-5/qsslerror.html>>
 
QSslCertificate::verify(QListhttps://doc.qt.io/qt-5/qsslcertificate.html#QSslCertificate>>
 certificateChain, const QString  
= QString())

Doing the same on iOS I'm getting "Unimplemented Code" logged and the list 
contains one entry "unknown error"

is this expected behaviour ?

thx

ekke

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

2020-02-05 Thread Mårten Nordheim 
Any chance we could get a stacktrace from the crash? Or does your build of Qt 
not have any symbols?

Mårten


Fra: Interest  på vegne av maitai 

Sendt: Tuesday, February 4, 2020 7:42:50 PM
Til: Interest@qt-project.org 
Emne: Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x


Thanks all for your help

Further findings:

The message concerning COM failing to initialize comes from our app, and is in 
fact there always in 5.14.x (regardless of the issue with QNetworkManager)

In the very first lines of main.cpp, we call a static function which for 
Windows does

HRESULT hres;

// Initialize COM.

hres =  CoInitializeEx(0, COINIT_MULTITHREADED);

if (FAILED(hres))

{

qWarning() << "Failed to initialize COM library. "

<< "Error code = 0x"

<< hex << hres << endl;

return QByteArray();

}

So this part is now broken in 5.14.x. If I put COINIT_APARTMENTTHREADED as a 
parameter for CoInitializeEx it seems to work again but I have to check a few 
other things before being 100% sure.

That being said, even if I remove this call and all references to WMI code and 
CoInitializeEx (including the links to wbemuuid and ws2_32), it still crashes 
if i do not create QNetworkManager before QApplication...

Philippe Lelong (a bit confused by all that, I must admit).



Le 04-02-2020 18:17, Rainer Wiesenfarth a écrit :

On Tue, Feb 4, 2020 at 5:18 PM Mårten Nordheim 
mailto:marten.nordh...@qt.io>> wrote:

It's likely related to the new network connection monitor inside 
QNetworkAccessManager, which uses COM.

Although that by itself shouldn't cause any issues and there's other uses of 
COM inside Qt as well. But perhaps you didn't indirectly use it so you didn't 
get a conflict earlier.

[...]


This sounds familiar. We ran into a similar issue with QFileDialog crashing due 
to the wrong COM threading model being active.

I do not recall the details, but searching for "CLR Thread Attribute" (a 
linking parameter) may give you some useful information.

Cheers, Rainer

--
Software Engineer | Trimble Imaging Division
Rotebühlstraße 81 | 70178 Stuttgart | Germany
Office +49 711 22881 0 | Fax +49 711 22881 11
http://www.trimble.com/imaging/ | http://www.inpho.de/

Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim
Eingetragen beim Amtsgericht Darmstadt unter HRB 83893,
Geschäftsführer: Rob Reeder, Jürgen Kesper

___
Interest mailing list
Interest@qt-project.org<mailto:Interest@qt-project.org>
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

2020-02-04 Thread Mårten Nordheim 
Hi!

It’s likely related to the new network connection monitor inside 
QNetworkAccessManager, which uses COM.
Although that by itself shouldn’t cause any issues and there’s other uses of 
COM inside Qt as well. But perhaps you didn’t indirectly use it so you didn’t 
get a conflict earlier.
I suppose it was bound to conflict with something sooner or later ;(

Apologies for the inconvenience!

Mårten

From: maitai
Sent: tirsdag 4. februar 2020 17:08
To: Interest@qt-project.org
Subject: Re: [Interest] Crash when creating QNetworkAccessManager in qt 5.14.x

Thanks Robert and Thiago,

If I create it on the stack instead of on the heap same mystery, i.e if
I create it before qApp all good, if after it crashes

this works:
 qWarning()<<"test";
 QNetworkAccessManager inet;
 qWarning()<<"after test";
 QApplication app(argc, argv);

this crashes:
 QApplication app(argc, argv);
 qWarning()<<"test";
 QNetworkAccessManager inet;
 qWarning()<<"after test";

Interesting is that in that last case I have a new message in the
console:

Failed to initialize COM library.  Error code = 0x -7ffefefa, before my
"test" qWarning()...

Googling it tells me it's about using WMI and it's true I do have some
WMI functions defined statically in an object.

Still that was working fine before 5.14.0 (5.13.2 for instance), and why
creating/deleting it before qApp fixes it all is beyond my level of
understanding...

Philippe Lelong.






Le 04-02-2020 16:43, Thiago Macieira a écrit :
> On Tuesday, 4 February 2020 01:45:27 PST coroberti . wrote:
>> Sorry, I meant allocation of QNetworkAccessManager object
>> by new operator (dynamic) versus its allocation on function scope
>> (static).
>
> Instead of static, please use automatic storage (no static, no new).
> Create it
> in the stack, after QApplication.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dark mode for other platforms

2019-10-16 Thread Mårten Nordheim 
On 16.10.2019 14:38, Vadim Peretokin wrote:
> But Qt on Windows doesn't automatically obey this dark mode like it does 
> on macOS - is there anything I can do to nudge it that way?

Unfortunately not, it just hasn’t been implemented in Qt yet for various 
reasons.

Although there has been some work on it recently by Friedemann
https://codereview.qt-project.org/c/qt/qtbase/+/275191
https://bugreports.qt.io/browse/QTBUG-72028

Mårten
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] Dark mode for other platforms

2019-10-16 Thread Mårten Nordheim 
On 16.10.2019 13:59, Nikos Chantziaras wrote:
> On 15/10/2019 13:46, Allan Sandfeld Jensen wrote:
>> On Tuesday, 15 October 2019 11:58:42 CEST Vadim Peretokin wrote:
>>> Hello!
>>>
>>> I've noticed that Qt on macOS now automatically uses dark mode, and it
>>> looks amazing
>>> . My
>>> question is: how can I enable this for Windows and Linux as well?
>>>
>> Linux and Window have had such modes forever.
> 
> Well, I wouldn't say "forever" in the case of Windows. It only got a 
> dark mode theme exactly 1 year ago (October 2018.) Which is one month 
> *after* macOS 10.14 was released (September 2018.)

Dark theme / dark mode was added in August 2016 :)
https://blogs.windows.com/windowsexperience/2016/08/08/windows-10-tip-personalize-your-pc-by-enabling-the-dark-theme/

Mårten
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] a question about QNetworkAccessManager

2019-03-20 Thread Mårten Nordheim 
One QNetworkAccessManager (QNAM for short) will be enough in your case as well. 
The signals on QNAM all pass a pointer to the QNetworkReply so you can know 
which it relates to.
Although perhaps more fitting for your usecase may be to use the signals on 
QNetworkReply instead of QNAM 
https://doc.qt.io/qt-5/qnetworkreply.html#finished?

Regards,
Mårten

From: Matej Košík
Sent: onsdag 20. mars 2019 10:47
To: interest@qt-project.org
Subject: [Interest] a question about QNetworkAccessManager

Hi,

I am new to Qt.
Yesterday, I have learned about:
- QNetworkAccessManager
- QNetworkRequest
- QNetworkReply
(as I wanted to figure out how to make HTTP GET/POST request and process the 
responses).

Here:

  https://doc.qt.io/qt-5/qnetworkaccessmanager.html#details

I read:

  One QNetworkAccessManager instance should be enough for the whole Qt 
application.

I do not understand what do I gain by that.
Our application makes different HTTP requests.
Each response must be handled differently.
Why would we want to pipe all "finished" signals (generated by the 
QNetworkAccessManager) to the same set of slots?
What sense would that make?

---

Curiously,
Matej

___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest

Re: [Interest] IFW issue: HTTP request returns a Not Acceptable

2018-09-19 Thread Mårten Nordheim 


On 18.09.2018 16:28, Kevin wrote:


Thanks for all the responses


An xml file can be compressed , too  Accept-Encoding is just a hint
to the server which compression the client accepts, and the server is free to
ignore it. So I doubt that's the issue.

I am just uploading whatever the repogen tool created for me.


My guess is the "?-915259074 " part of the url is what makes the server fail.



To prevent caching, you may wish instead to add header:
Cache-Control: no-store
For the above suggestions, how do I do that through the IFW? Are there 
config.xml parameters that I missed?


Is it possible for you to lighten the restriction on the User-Agent 
in ModSecurity in this case?
I have tried to disable modsecurity completely to debug this issue, 
and it does not help unfortunately.

Was the output any different once modsecurity was disabled?

You can try with this command:
curl -i 
http://www.spikegadgets.com/downloads/onlinesoftwarerepo/Updates.xml?-763156944 
-H "User-Agent: Mozilla/5.0"


Mårten
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] IFW issue: HTTP request returns a Not Acceptable

2018-09-18 Thread Mårten Nordheim 

Hey,

I used curl a bit to test things out with the address you provided. The 
request is rejected by "Mod_Security" seemingly due to the User-Agent. 
The options here are limited since it seems IFW doesn't let you change 
User-Agent ( https://bugreports.qt.io/browse/QTIFW-671 ). Is it possible 
for you to lighten the restriction on the User-Agent in ModSecurity in 
this case?


Mårten


On 18.09.2018 01:33, Kevin Wang wrote:


Hi All,

I am attempting to utilize the Qt Installer Framework for our 
company's software. I am just starting out and am running into some 
issues.


I uploaded the generated repo to our website, and linked the repo in 
the installer. When I run the installer and attempt to fetch the 
remote repo tree, it returns this:


"Cannot retrieve remote tree. "

Using the --verbose option, it says this:

[1744] Network error while downloading

'http://www.spikegadgets.com/downloads/onlinesoftwarerepo/Updates.xml?-763156944':
Error transferring

http://www.spikegadgets.com/downloads/onlinesoftwarerepo/Updates.xml?-763156944
- server replied: Not Acceptable.
[1745] Cannot fetch a valid version of Updates.xml from repository
"": "unexpected character"
[1751] Cannot retrieve remote tree .

You can even go to the link above in a browser and see that it is 
uploaded properly.


I sniffed out the HTTP request and it showed that the IFW sent this:

GET /downloads/onlinesoftwarerepo/Updates.xml?-915259074 HTTP/1.1
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*
User-Agent: Mozilla/5.0
Host: www.spikegadgets.com


So I have absolutely no experience in web servers and HTTP requests 
and such. The website and FTP was set up for us, which I used to 
upload the repo. To me, the issue seems to be that the Installer 
framework is sending a HTTP request for an encoding that doesn't make 
sense ("Accept-Encoding: gzip, deflate" for a .xml file?).


Is there something I am missing? Doing wrong? What should I look into 
to fix this?


Kevin



___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest

Re: [Interest] Detecting subdirectories in QDir

2018-07-12 Thread Mårten Nordheim 

Does it work properly if 'b' is root?

On 11.07.2018 17:59, Oleg Yadrov wrote:

Ha. I hope I didn't screw up this time.

#include

#include

#include


//returnstrueif'a'isasubdirectoryof'b'

boolisSubdirectory(QDira,QDirb)

{

while(!a.isRoot()){

if(a.absolutePath()==b.absolutePath())

returntrue;

a.cdUp();

}

returnfalse;

}


intmain(intargc,char*argv[])

{

QCoreApplicationapp(argc,argv);


QDira("/Users/olegyadrov/one/two/three");

QDirb("/Users/olegyadrov/one/two");

QDirc("/Users/olegyadrov/one/four");


qDebug()> wrote:


On Wednesday, 11 July 2018 07:44:46 PDT Oleg Yadrov wrote:

   qDebug() << a.absolutePath().startsWith(b.absolutePath());

   qDebug() << a.absolutePath().startsWith(c.absolutePath());


Except that this has a bug (which we had in Qt too): these two 
directories are

considered to be parent-child, when they're not

C:\One\TwoAndTwenty
C:\One\Two

And since we're talking about Windows, you also need to use 
case-insensitive

comparison.
--
Thiago Macieira - thiago.macieira (AT) intel.com 
 Software Architect - Intel Open Source Technology Center



___
Interest mailing list
Interest@qt-project.org 
http://lists.qt-project.org/mailman/listinfo/interest




___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest