Re: [Interest] signing webenginewidgets issue

[Hamish Moffatt via Interest]

Hmm, I have different entitlements set here, as per 
https://forum.qt.io/topic/102212/qtwebengine-signing-issues/20


In short, the QtWebEngineProcess.app Helper within 
QtWebEngineCore.framework is signed with 
com.apple.security.cs.disable-executable-page-protection true.


Runtime is hard and the application is signed, notarised and packaged 
(and signed).


Hamish

On 15/6/24 22:23, Alexander Carôt via Interest wrote:

P.S.: Nevermind – I simply did not wait long enough for the app to be 
notarized. The solution for me was to only include this key:

com.apple.security.cs.allow-jit

and then I could sign, notarize and launch.


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



Gesendet: Samstag, 15. Juni 2024 um 13:44 Uhr
Von: "Alexander Carôt via Interest" 
An: "qt qt" 
Betreff: [Interest] signing webenginewidgets issue

Hello all,

I just saw an issue when signing and notarizing an app containing a web browser 
based on webenginewidgets (applies also for the Qt example minibrowser):

1.) Codesigning via

codesign --options=runtime --deep ./minibrowser.app -s "Developer ID Application: 
XXX"

works fine but breaks the app: Launching minibrowser afterwards makes the 
webprocess crash.

2.) Including the following keys into an entitlements file:

com.apple.security.cs.allow-jit
com.apple.security.cs.disable-library-validation
com.apple.security.cs.allow-dyld-environment-variables
com.apple.security.cs.allow-unsigned-executable-memory

and then signing via

codesign --options=runtime --entitlements ./entitlements.xml --deep ./minibrowser.app -s 
"Developer ID Application: XXX"

does not lead to the crash anymore and

codesign --verify --deep --strict --verbose=2 ./minibrowser.app

tells that all is signed just fine, however, when I package the app as a DMG, 
load it up to the web, load it down to my desktop and launch it, it tells me 
that the developer cannot be verified – so it basically tells that it is not 
signed.

The same happens when I only include the first key:

com.apple.security.cs.allow-jit

but here comes the message that the package cannot be opened because it cannot 
be checked in terms of malware etc.

Can anyone help with this ?

Thanks a lot 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


___
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 build on Raspi

[Hamish Moffatt via Interest]

Hi Alexander,

All the modules are available - see in 
https://archive.raspbian.org/raspbian/pool/main/q/

Hamish

Sent from Nine<http://www.9folders.com/>

From: Alexander Carôt 
Sent: Monday, March 25, 2024 16:06
To: Hamish Moffatt
Cc: interest@qt-project.org
Subject: Aw: Re: [Interest] Qt6 build on Raspi

Hi Hamish,

>>> https://archive.raspbian.org/raspbian/pool/main/q/qt6-base

I will give it a try but before I start I wonder if the following modules are 
also available because I can't spot them on the directory:

websockets
webengine
multimedia
multimediawidgets

Thanks for letting me know,
best

Alex

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


> Gesendet: Sonntag, 10. März 2024 um 08:25 Uhr
> Von: "Hamish Moffatt via Interest" 
> An: interest@qt-project.org
> Betreff: Re: [Interest] Qt6 build on Raspi
>
> On 9/3/24 20:57, Alexander Carôt via Interest wrote:
> >>>> ... or build on a system with sufficient RAM.
> > I see – can I use any ARM based machine in order to work on a Raspi4 or are 
> > there specific requirements ?
> >
> > Furthermore, I might have missed something but are there probably pre-built 
> > Qt6 binaries for Raspi available ?
> >
> It's in Debian 12 (bookworm) and Raspbian bookworm.
> https://archive.raspbian.org/raspbian/pool/main/q/qt6-base/
>
> That's the open source edition. If you need commercial then I think you
> have to build it yourself on another armhf system.
>
>
> Hamish
>
> ___
> 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 build on Raspi

[Hamish Moffatt via Interest]

On 9/3/24 20:57, Alexander Carôt via Interest wrote:

... or build on a system with sufficient RAM.

I see – can I use any ARM based machine in order to work on a Raspi4 or are 
there specific requirements ?

Furthermore, I might have missed something but are there probably pre-built Qt6 
binaries for Raspi available ?

It's in Debian 12 (bookworm) and Raspbian bookworm. 
https://archive.raspbian.org/raspbian/pool/main/q/qt6-base/


That's the open source edition. If you need commercial then I think you 
have to build it yourself on another armhf system.



Hamish

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

Re: [Interest] [Qt bugreports] Updates for QTBUG-122109: QTreeWidget's columns do not seem to resize properly after upgrading from Qt6.5.3 to Qt6.1.1

[Hamish Moffatt via Interest]

On 6/3/24 17:40, Jani Heikkinen via Interest wrote:


Hi!

Yeah, no snapshot or release yet having this fix. The fix will be in 
Qt 6.7.0 RC, which should be released soon, most probably at the 
beginning of next week




Jira says it is fixed in 6.5.5, which isn't correct.

Hamish

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

Re: [Interest] Modeless dialog issue on Mac

[Hamish Moffatt via Interest]

On 15/11/23 21:01, Calogero Mauceri wrote:
The problem of using Qt::WindowStaysOnTopHint is that the dialog stays 
on top of any desktop application while it has to be on top of the 
application level only. Here is what I mean



We grappled with this too. It actually worked well in earlier versions 
of Qt (a long time ago).


We worked around it by watching for application state change events and 
dynamically removing the WindowStaysOnTop flag when the application 
loses focus.



Tor writes that this is normal behaviour on macOS, but it's not 
consistent with other Qt platforms.




Hamish

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

Re: [Interest] QEvent::Quit vs. QEvent::Close

[Hamish Moffatt via Interest]

On 24/10/23 06:10, Alexander Dyagilev wrote:
I would prefer for an additional event to be used when the user 
triggers Quit. E.g. something like QEvent::QuitByUser.


For now, it seems I will have to involve some additional ugly logics 
(something like setting a global variable) More code more 
complexity for such a simple situation. Not good, IMO. 



Does QEvent::spontaneous() tell you anything about the two different 
quit events?


Hamish

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

Re: [Interest] Qt Installer Framework - add menu entries under Linux

[Hamish Moffatt via Interest]

On 9/9/23 19:14, Petric Frank wrote:

Hello,

there is an example to add start menu entries for the windows platform.

But how to do it for the Linux platform - here: Debian 12 (Bookworm) ?

Platform: Debian 12
WM: KDE Plasma
Qt 5.15.2 (by Online Installer from qt.io)



You need to create a .desktop file in the right place.


https://wiki.archlinux.org/title/Desktop_entries

https://specifications.freedesktop.org/desktop-entry-spec/latest/



Hamish

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

Re: [Interest] slower compilation with Qt6

[Hamish Moffatt via Interest]

On 24/7/23 17:01, Cristian Adam wrote:
The compilation time degradation is being tracked at [QTBUG-97601] 
Compilation speed decrease with Qt 6.2 compared to Qt 5.15.2 - Qt Bug 
Tracker 


For Qt Creator I use https://ccache.dev/ (yes, it works with MSVC) so 
that even if it takes longer to compile, I won't be compiling the same 
file in same situation twice.



Thanks, good to know this a known issue with work in progress. I do use 
ccache on my linux builds, though I'm finding it increasingly unreliable 
with PCH enabled so I will have to decide which is more useful.



My test compile results for 5.15.13 versus 6.5.2 are even worse than the 
figures you reported in that issue.



For a project with ~600 TUs, compiled on linux with clang 14, PCH on but 
no ccache, I see 40 seconds -> 96 seconds.



For another project with ~900 TUs, compiled with MSVC 2022 with jom, PCH 
on but no ccache, I see 178 seconds -> 332.




I compile with CONFIG += c++2a on both Qt versions.


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

[Interest] slower compilation with Qt6

[Hamish Moffatt via Interest]

I've just finished porting my application from Qt 5.15 to 6.5, and I'm 
finding that compilation is significantly slower now - builds take twice 
as long or more. For example a linux-g++ build of a project with ~650 .o 
files has gone from 45 seconds to 100. I see similar increases on 
Windows with MSVC2022, and in other projects with more compilation units.


I'm already using precompiled headers, including a bunch of Qt headers 
and some STL.


The next MSVC2022 preview release has a "Build Insights" feature which 
shows time spent processing header files, and my biggest culprits are 
some headers of mine that use a lot of Q_GADGET and Q_PROPERTY macros.



Does anyone have any suggestions on how to speed things up? I see some 
other comments about this online for example 
https://forum.qt.io/topic/142309/compilation-times-with-qt6/12




Thanks

Hamish



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

Re: [Interest] unresolved WinMain on porting to Qt 6

[Hamish Moffatt via Interest]

On 23/6/23 22:16, Henry Skoglund wrote:

On 2023-06-23 07:15, Hamish Moffatt via Interest wrote:


If I add the linker flag /ENTRY:mainCRTStartup then it builds. What's 
the correct Qt solution for this though?




The fact that adding /ENTRY:mainCRTStartup helped implies that you're 
linking with /SUBSYSTEM:CONSOLE and not /SUBSYSTEM:WINDOWS, i.e. 
defaulting to console flavor.
Maybe you forgot "QT += widgets" in the .pro file (just guessing :-) 



That wasn't it (widgets were including and linking fine), but what I 
figured out is that the magic helper in Qt5 qtmain is now the library 
Qt6EntryPoint, and for some reason that wasn't being linked. Reading the 
qmake debug logs, the entrypoint-private module gets added to QT_PRIVATE 
during processing but then vanishes before it's used. In a test 
application, the entrypoint-private module then adds 
entrypoint-implementation which links the library and all is good.


I have no idea why entrypoint-private is disappearing from QT_PRIVATE, 
but I just added entrypoint-implementation to QT directly and I'll live 
with that for now.


Hamish

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

[Interest] unresolved WinMain on porting to Qt 6

[Hamish Moffatt via Interest]

I'm porting my applications to Qt6, from 5.15. Still using qmake. My 
console applications build and run fine, but my widgets applications 
fail to link with an error (Windows, VS 2022):


1>MSVCRTD.lib(exe_winmain.obj) : error LNK2019: unresolved external 
symbol WinMain referenced in function "int __cdecl invoke_main(void)" 
(?invoke_main@@YAHXZ)


I have a traditional entrypoint: int main(int argc, char* argv[]).


I see in Qt 5 there was a magic helper library qtmain, but this does not 
exist in Qt 6.


If I add the linker flag /ENTRY:mainCRTStartup then it builds. What's 
the correct Qt solution for this though?



Thanks

Hamish

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

Re: [Interest] Qt 6.4.3 compiler warnings in QTaggedPointer

[Hamish Moffatt via Interest]

On 23/3/23 18:15, Thiago Macieira wrote:

On Wednesday, 22 March 2023 18:19:59 HST Hamish Moffatt via Interest wrote:

static constexpr quint8 tagBits =
QtPrivate::qConstexprCountTrailingZeroBits(alignment);

So would you fix it with a cast, or by changing the variable type to int
to match the function?

Either solution is fine. I was thinking of simply adding a quint8() cast around
the result, but changing to uint also works too. The latter is a smaller
change anyway.

OK. There's a similar issue in QtConcurrent (unchanged since 5.15 
actually) also driving me mad - __int64 resulting from std::distance is 
assigned to int.



Hamish

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

Re: [Interest] Qt 6.4.3 compiler warnings in QTaggedPointer

[Hamish Moffatt via Interest]

On 23/3/23 05:00, Thiago Macieira wrote:


I don't see any changes since v6.4 that would fix that. It looks trivial though
to apply an explicit cast to silence that warning.

Any chance you can contribute it?


I started with a bug report, anyway: QTBUG-11.


static constexpr quint8 tagBits = 
QtPrivate::qConstexprCountTrailingZeroBits(alignment);


So would you fix it with a cast, or by changing the variable type to int 
to match the function?



Hamish

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

Re: [Interest] Qt 6.4.3 compiler warnings in QTaggedPointer

[Hamish Moffatt via Interest]

On 22/3/23 18:12, Thiago Macieira wrote:

On Tuesday, 21 March 2023 20:18:17 HST Hamish Moffatt via Interest wrote:

I'm porting from Qt 5.15.12 to 6.4.3, and now MSVC 2019 is giving me a
ton of compiler warnings about QTaggedPointer.

[cut]

Any suggestions on how to shut it up?

Stop using 2019, please. That compiler has a number of unfixed bugs.



Sorry, brain fart. It is indeed 2022, version 17.5.2 - the very latest.


Hamish

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

[Interest] Qt 6.4.3 compiler warnings in QTaggedPointer

[Hamish Moffatt via Interest]

I'm porting from Qt 5.15.12 to 6.4.3, and now MSVC 2019 is giving me a 
ton of compiler warnings about QTaggedPointer.


I don't know what that is, except I see it used in qproperty.h and I use 
a lot of Q_GADGET classes with Q_PROPERTYs.


I'm using /W3 in MSVC and compiling for 64-bit. I've enabled some extra 
warnings on top, but not C2424.



Any suggestions on how to shut it up?

Hamish



1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qtaggedpointer.h(24,1): 
warning C4242: 'initializing': conversion from 'uint' to 'const quint8', 
possible loss of data
1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qtaggedpointer.h(55,1): 
message : see reference to class template instantiation 
'QtPrivate::TagInfo' being compiled

1>    with
1>    [
1>    T=quint16
1>    ]
1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qtaggedpointer.h(49,1): 
message : while compiling class template member function 
'QTaggedPointer::Tag>::QTaggedPointer(T 
*,Tag) noexcept'

1>    with
1>    [
1>    Storage=quint16,
1>    T=quint16,
1> Tag=QtPrivate::QConstPreservingPointer::Tag
1>    ]
1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qiterable.h(32,24): 
message : see reference to function template instantiation 
'QTaggedPointer::Tag>::QTaggedPointer(T 
*,Tag) noexcept' being compiled

1>    with
1>    [
1>    Storage=quint16,
1>    T=quint16,
1> Tag=QtPrivate::QConstPreservingPointer::Tag
1>    ]
1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qiterable.h(19): 
message : see reference to class template instantiation 
'QTaggedPointer::Tag>' 
being compiled

1>    with
1>    [
1>    Storage=quint16
1>    ]
1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qiterable.h(413): 
message : see reference to class template instantiation 
'QtPrivate::QConstPreservingPointer' being compiled
1>C:\qt\Qt6.4.2\6.4.2\msvc2019_64\include\QtCore\qiterable.h(508,2): 
message : see reference to class template instantiation 
'QIterable' being compiled


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

Re: [Interest] can't dump QStringList with qDebug()

[Hamish Moffatt via Interest]

On 8/3/23 14:45, Thiago Macieira wrote:

On Tuesday, 7 March 2023 17:21:11 PST Hamish Moffatt via Interest wrote:

I said gcc 10 earlier, but I meant to say clang 11. But I also see it in
clang 14, and in VS 2019 (17.5.1 - latest).

Cannot reproduce with those files with GCC 11, 12, 13 or Clang 15, all with Qt
6.6.

Looking at the generated assembly, I can also see the compiler realised the
list is always empty, so the loop from printSequentialContainer() disappears.f



I confirm that my test code compiles in 6.5.0-beta3.


thanks

Hamish

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

Re: [Interest] can't dump QStringList with qDebug()

[Hamish Moffatt via Interest]

On 8/3/23 04:15, Thiago Macieira wrote:

On Monday, 6 March 2023 22:15:01 PST Hamish Moffatt via Interest wrote:

../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdebug.h:217:53: note:
candidate template ignored: requirement
'std::conjunction_v,
QString>, QTypeTraits::has_ostream_operator>>' was
not satisfied [with T = QString]

This is the expected template and the compiler told us why it couldn't expand:
it thinks that the QDebugIfHasDebugStreamContainer condition wasn't satisfied.
That condition is

std::is_base_of OR QTypeTraits::has_ostream_operator

Obviously, QStringList is not a base class of QString; we're expecting the
second check to be true, that there's an output streaming operator for QDebug-
QString

That of course is there; it's in QDebug itself.

So my conclusion is that your compiler has a bug and improperly parsed the C++
code. Does this problem happen with GCC 11 or 12?

I said gcc 10 earlier, but I meant to say clang 11. But I also see it in 
clang 14, and in VS 2019 (17.5.1 - latest).


It seems to be related to #including the moc output in the cpp file.


Here's a minimal example:

Header file:

#pragma once

#include 
#include 

namespace TServer
{

class Test : public QObject
{
Q_OBJECT

private:
void test();

signals:
void databaseOpened(QString schoolCode);
void databaseEvent(QString schoolCode, QString notification);
void databaseRemoved(QString schoolCode, QString dbFilename);
};

}


Source file:

#include "server_database2.h"
#include 

#include 


void TServer::Test::test()
{
qDebug() << QStringList{};
}



Hamish

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

Re: [Interest] can't dump QStringList with qDebug()

[Hamish Moffatt via Interest]

On 7/3/23 20:11, Kai Köhne wrote:

Hi,

This looks like a compiler issue to me.

 const auto connections = QSqlDatabase::connectionNames();
 qDebug() << "Closing open connections:" << connections;

claiming that
../../../src/server/server_database.cpp:691:45: error: invalid operands to binary 
expression ('QDebug' and>
'const QList')

I think this is the place where it goes wrong:


../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdebug.h:217:53: note: candidate template ignored: 
requirement 'std::conjunction_v, QString>, 
QTypeTraits::has_ostream_operator>>' was not satisfied [with T = QString]
inline QDebugIfHasDebugStreamContainer, T> operator<<(QDebug debug, const 
QList )
 ^

Anyhow, I couldn't reproduce this in a minimal example (and apparently you 
didn't manage either?). At minimum we need the exact compiler + compiler 
options passed on command line.



It's happening in both Visual C++ and gcc 10, but on further 
investigation, only in one .cpp file; the same code in other files works 
fine. I'll keep investigating.



thanks

Hamish

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

[Interest] can't dump QStringList with qDebug()

[Hamish Moffatt via Interest]

I'm porting my code to Qt6 (6.4.2) (from 5.15) and ran into this 
mysterious problem; this code doesn't compile:


    const auto connections = QSqlDatabase::connectionNames();
    qDebug() << "Closing open connections:" << connections;


claiming that

../../../src/server/server_database.cpp:691:45: error: invalid operands 
to binary expression ('QDebug' and 'const QList')


It then lists all the candidates, of which there are many.  I have a 
simple test program that compiles OK though.


The same occurs on both Visual Studio/Windows and gcc 10/Linux.

Am I missing an include or something?


Hamish



../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdatastream.h:398:1: note: 
candidate function template not viable: no known conversion from 'QDebug' to 
'QDataStream &' for 1st argument
operator<<(QDataStream , const T )
^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdatastream.h:415:63: note: 
candidate function template not viable: no known conversion from 'QDebug' to 
'QDataStream &' for 1st argument
inline QDataStreamIfHasOStreamOperatorsContainer, T> operator<<(QDataStream , 
const QList )
  ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qobject.h:491:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QObject *' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, const QObject *);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtSql/qsqldatabase.h:105:21: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QSqlDatabase' for 2nd argument
Q_SQL_EXPORT QDebug operator<<(QDebug, const QSqlDatabase &);
^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdebug.h:447:15: note: candidate 
function not viable: no known conversion from 'const QList' to 
'QKeyCombination' for 2nd argument
inline QDebug operator<<(QDebug debug, QKeyCombination combination)
  ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qiodevice.h:143:22: note: candidate 
function not viable: no known conversion from 'const QList' to 
'QIODevice::OpenMode' (aka 'QFlags') for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug debug, QIODevice::OpenMode modes);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qvariant.h:560:28: note: candidate 
function not viable: no known conversion from 'QDebug' to 'QDataStream &' for 
1st argument
Q_CORE_EXPORT QDataStream <<(QDataStream , const QVariant );
   ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qvariant.h:622:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QVariant::Type' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, const QVariant::Type);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlocale.h:1142:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QLocale' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, const QLocale &);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdatetime.h:540:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'QDate' 
for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, QDate);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdatetime.h:541:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'QTime' 
for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, QTime);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdatetime.h:542:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QDateTime' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, const QDateTime &);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qfileinfo.h:175:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QFileInfo' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug, const QFileInfo &);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdir.h:244:22: note: candidate function not 
viable: no known conversion from 'const QList' to 'QDir::Filters' (aka 
'QFlags') for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug debug, QDir::Filters filters);
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qdir.h:245:22: note: candidate 
function not viable: no known conversion from 'const QList' to 'const 
QDir' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug debug, const QDir );
 ^
../../../../Qt6.4.2/6.4.2/gcc_64/include/QtCore/qregularexpression.h:166:22: note: 
candidate function not viable: no known conversion from 'const QList' 
to 'const QRegularExpression' for 2nd argument
Q_CORE_EXPORT QDebug operator<<(QDebug debug, const QRegularExpression );
 ^

Re: [Interest] use of deleted function errors in QList / qarraydataops.h

[Hamish Moffatt via Interest]

On 28/2/23 12:00, Hamish Moffatt via Interest wrote:
Qt5's documentation (like Qt6's) does say "QVector's value type must 
be an assignable data type", so the mystery here is perhaps why our 
code works with Qt5. 



Even in Qt6, it compiles with other things in the struct that aren't 
assignable though, just not QVector.


struct T
{
int x = 0;
};

struct S
{
//const QVector v; // compiles if not const
const T t;
const int x = 0;
};

QVector pv;
pv.push_back({});



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

Re: [Interest] use of deleted function errors in QList / qarraydataops.h

[Hamish Moffatt via Interest]

On 28/2/23 11:49, Thiago Macieira wrote:

On Monday, 27 February 2023 16:22:46 PST Hamish Moffatt via Interest wrote:

How and when would Qt5 show an error? We have the above code working and
in production, and I'm able resize, copy and change, force a detach -
operations where QVector would need to copy elements.

Ah, looks like it isn't going to. I expected the issue was that it didn't
happen in this test case because it never detached. If you're definitely
detaching, then this isn't the same issue.

The issue here is that you have a type that is copy/move constructible, but
cannot be copy/move assigned. That's usually a bad combination; the new QList/
QVector code uses move-assignment when moving elements in the overlapping part
of the list.

We could determine that your type is not move-assignable and use a different
strategy, but this isn't implemented right now. It might be less efficient; I
wouldn't know.



Qt5's documentation (like Qt6's) does say "QVector's value type must be 
an assignable data type", so the mystery here is perhaps why our code 
works with Qt5.



Thanks,

Hamish

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

Re: [Interest] use of deleted function errors in QList / qarraydataops.h

[Hamish Moffatt via Interest]

On 28/2/23 11:14, Thiago Macieira wrote:

On Monday, 27 February 2023 13:05:01 PST Hamish Moffatt via Interest wrote:

On 28/2/23 04:14, Thiago Macieira wrote:

On Sunday, 26 February 2023 23:24:43 PST Hamish Moffatt via Interest wrote:

Is there a solution?

Remove the const in:
   struct S
   {
   
   const QVector v; // compiles if not const
   
   };


If S is not copyable, then QVector can't copy it and QVector requires
copying all its elements.

May I ask why that is? Qt5 QVector and std::vector are both OK with the
above.

Qt 5 QVector is not ok with the above, it just hasn't produced an error *yet*.
All Qt main containers are implicitly-shared and therefore must be able to
copy their elements. Therefore, your elements must be copyable.

std::vector doesn't have this requirement. It is copyable if the element is
copyable, otherwise it isn't.

How and when would Qt5 show an error? We have the above code working and 
in production, and I'm able resize, copy and change, force a detach - 
operations where QVector would need to copy elements.



Hamish

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

Re: [Interest] use of deleted function errors in QList / qarraydataops.h

[Hamish Moffatt via Interest]

On 28/2/23 04:14, Thiago Macieira wrote:

On Sunday, 26 February 2023 23:24:43 PST Hamish Moffatt via Interest wrote:

Is there a solution?

Remove the const in:

  struct S
  {
  const QVector v; // compiles if not const
  };

If S is not copyable, then QVector can't copy it and QVector requires copying
all its elements.


May I ask why that is? Qt5 QVector and std::vector are both OK with the 
above.



Hamish

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

[Interest] use of deleted function errors in QList / qarraydataops.h

[Hamish Moffatt via Interest]

I have some code which boils down to this:


#include 

void test()

{

    struct S

    {

        const QVector v; // compiles if not const

    };

    QVector> pv; // doesn't compile with this

    //std::vector> pv; // compiles with this

    pv.push_back(std::make_pair({}, {}));

}


This compiles in Qt 5.15.12, but not in 6.4.2.

The last line generates no less than 4 errors, resulting in pages and 
pages of output, but essentially:


../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h:472:29: error: use of deleted function 
‘std::pair& std::pair::operator=(const 
std::pair&)’
  472 | last[i] = std::move(last[i - 1]);
  | ^~~~
--
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h:475:24: error: use of deleted function 
‘std::pair& std::pair::operator=(const 
std::pair&)’
  475 | *where = std::move(t);
  | ~~~^~
--
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qcontainertools_impl.h:132:18: error: use of deleted 
function ‘std::pair& std::pair::operator=(const std::pair&)’
  132 | *d_first = std::move_if_noexcept(*first);
  | ~^~~
--
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qcontainertools_impl.h:132:18: error: use of deleted 
function ‘std::pair& std::pair::operator=(const std::pair&)’


As per the comments, it compiles if the member variable in the inner 
struct is not const, or if I use a std::vector instead of QVector.


Is there a solution?

Full error text below.


Hamish




In file included from 
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydatapointer.h:7,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlist.h:8,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qvector.h:7,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/QVector:1,

 from test.cc:1:

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h: In instantiation of ‘void 
QtPrivate::QGenericArrayOps::Inserter::insertOne(qsizetype, T&&) [with T = 
std::pair; qsizetype = long long int]’:

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h:557:37:   required from ‘void 
QtPrivate::QGenericArrayOps::emplace(qsizetype, Args&& ...) [with Args = 
{std::pair}; T = std::pair; qsizetype = long long 
int]’

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlist.h:852:15:   required from ‘T& 
QList::emplaceBack(Args&& ...) [with Args = {std::pair}; T = 
std::pair; QList::reference = std::pair&]’

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlist.h:440:24:   required from ‘void 
QList::append(QList::rvalue_ref) [with T = std::pair; 
QList::rvalue_ref = std::pair&&]’

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlist.h:652:42:   required from ‘void 
QList::push_back(QList::rvalue_ref) [with T = std::pair; 
QList::rvalue_ref = std::pair&&]’

test.cc:13:43:   required from here

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h:472:29: error: use of deleted function 
‘std::pair& std::pair::operator=(const 
std::pair&)’

  472 | last[i] = std::move(last[i - 1]);

  | ^~~~

In file included from /usr/include/c++/10/utility:70,

 from 
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qglobal.h:11,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qpair.h:7,

 from 
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydata.h:8,

 from 
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h:8,

 from 
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydatapointer.h:7,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlist.h:8,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qvector.h:7,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/QVector:1,

 from test.cc:1:

/usr/include/c++/10/bits/stl_pair.h:211:12: note: ‘std::pair& 
std::pair::operator=(const std::pair&)’ is 
implicitly declared as deleted because ‘std::pair’ declares a move constructor or 
move assignment operator

  211 | struct pair

  |    ^~~~

In file included from 
../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydatapointer.h:7,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qlist.h:8,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qvector.h:7,

 from ../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/QVector:1,

 from test.cc:1:

../../dev/Qt6.4.2/6.4.2/gcc_64/include/QtCore/qarraydataops.h:475:24: error: use of deleted function 
‘std::pair& std::pair::operator=(const 
std::pair&)’

  475 | *where = std::move(t);

  | ~~~^~

In file included from 

Re: [Interest] MSVC not-the-latest: are you using it? why?

[Hamish Moffatt via Interest]

On 26/1/23 03:52, Thiago Macieira wrote:
The reason I asked about VS2019, aside from the simple learning of 
many things

I did not anticipate, is that we're seeing it have C++ compliance issues. This
is not even C++20 or 17; it's a plain constexpr function that should have
worked with C++14.

Is it actually VS 2019 you want to drop, or the v142 toolset and 
earlier? Because VS2022 would support compiling with v142 also (and 
earlier) but I guess that's what doesn't work.


We have used older compilers in newer VS in the past, but not for any 
good particularly good reason other than being conservative about upgrading.



Hamish

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

[Interest] QScopedPointer::create

[Hamish Moffatt via Interest]

Is there any reason why QScopedPointer doesn't have a create static 
method, like QSharedPointer does?


I didn't see any requests for it in jira. Should I just use unique_ptr 
instead?


Hamish

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

Re: [Interest] Qt 6.5 Is Irrelevant...

[Hamish Moffatt via Interest]

On 21/12/22 06:38, Allan Sandfeld Jensen wrote:

On Montag, 19. Dezember 2022 16:59:41 CET Michael Jackson wrote:

So not really a “jolt every 3 years”. You have had 3 _total_ jolts over the
course of 30 years.


Except them dropping support for pre-AVX, pre-AVX2 CPUs,



Big Sur (macOS 11), released 2.5 years ago and still supported, runs on 
Macs dating back to 2013. https://support.apple.com/en-us/HT211238


I suffer from this problem too (users sticking to old OS releases), but 
I don't think Apple is being too unreasonable in this particular case.



Hamish

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

Re: [Interest] Official linuxdeployqt ?

[Hamish Moffatt via Interest]

On 9/8/22 23:50, Roland Hughes via Interest wrote:


On 8/9/22 05:00, Vadim Peretokin wrote:

Just to correct some biases here, in my opinion as a software publisher
AppImage is still the simplest way for a user to run your app.?

To get Mudlet (a FOSS text games client) all you need to do is go to
https://www.mudlet.org/download, download the .tar, right-click to
extract it and double-click to run.?


Not to discount your experience, but I've been in IT almost 40 years 
now. Not once in my career have I ever used an AppImage. I have used 
Debian, RPM, Snap, and Flatpak.


Most companies and many Linux distros have started making it more 
difficult for someone to "just download and install from a Web site" 
because Malware is everywhere.


When your OpenSource project includes the scripts to make a proper 
Debian or RPM package, you dramatically increase the odds of getting 
your package into the actual distro repos. Does any distro actually 
put AppImage files in their repo? I'm asking. I have never heard of it 
but that doesn't mean there isn't some obscure distro doing that. 



I have never used an AppImage in 25 years of Debian and Linux experience 
either. It sounds equivalent to downloading a random unsigned .EXE from 
a web site and running it. I prefer official deb packages, or OCI/Docker 
container images, or at least a proper third party deb (ideally in a 
repository).



Flatpak offers signed builds and sandboxing. If you were going to build 
a deployment format into linux deployqt it would have to be a modern 
format that included signing and sandboxing.



regards

Hamish

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

Re: [Interest] Official linuxdeployqt ?

[Hamish Moffatt via Interest]

On 8/8/22 16:09, Jörg Bornemann wrote:
Mitch already pointed you to QTBUG-74940.  The biggest question 
regarding a linuxdeployqt is: what exactly is the deployment format 
going to be?  There's no standard way of deploying Linux applications. 
There are many.


The community contributions create AppImage packages.  That seems to 
be a reasonable choice.  Other opinions?



Like Roland said, it has to be Flatpak. I haven't seen anyone talking 
about AppImage in years, and Snap is too Ubuntu-specific.



windeployqt doesn't package anything though, so should linuxdeployqt? 
macdeployqt only sort of does, with its dmg support.



Hamish

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

Re: [Interest] QtWebEngine crash after codesign

[Hamish Moffatt via Interest]

On 30/4/22 00:56, Alexander Carôt wrote:

codesign --options=runtime --deep ./simplebrowser.app -s "Developer ID 
Application:–xyz"


The hardened runtime (--options=runtime) causes the web engine to crash. 
You need to add entitlements while signing it.


See: https://forum.qt.io/topic/102212/qtwebengine-signing-issues/4

You only need that on the web engine process, not the whole application, 
which messes with the --deep a bit.



Hamish

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

Re: [Interest] webengine for iOS

[Hamish Moffatt via Interest]

On 29/4/22 15:32, Alexander Carôt wrote:
>>>Apple don't allow the use of any browser on iOS except the the 
system web view.
Wow – again I am "amazed" by the tough iOS restrictions. I have never 
experienced such huge amount of regulations before. Well, it has its 
pros and cons, however, from the developer's point of view it's kind 
of a pain ... sometimes ;-)


Even Chrome and Firefox on iOS are actually just wrappers around the iOS 
web view.


It has been argued that this is anti-competitive behaviour on Apple's 
part, but unless you can convince a regulator of that nothing will change.




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

Re: [Interest] webengine for iOS

[Hamish Moffatt via Interest]

On 29/4/22 04:30, Alexander Carôt wrote:

>>There is no qtwebenigne on ios , use qtwebview instead.
Ah – ok, good to know but I'd also be curious to know why.



Apple don't allow the use of any browser on iOS except the the system 
web view.



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

Re: [Interest] macdeployqt on Monterey 12.3.1

[Hamish Moffatt via Interest]

On 27/4/22 18:25, Hamish Moffatt wrote:

On 27/4/22 17:05, Alexander Carôt wrote:
>>That's not guaranteed to work. Major versions 7 and 8 are unlikely 
to be compatible (else they wouldn't have changed the version number 
with all the difficulty that creates).
Agreed, however, the question is if anyone else besides me can 
reproduce the issue so I can file a bug report.

At least the solution works as a temporary workaround for me.


Your error message said

ERROR: "dyld[17429]: Library not loaded: /opt/local/lib/libffi.7.dylib\n  Referenced 
from: /opt/local/libexec/llvm-10/lib/libLLVM.dylib\n  Reason: tried: 
'/opt/local/lib/libffi.7.dylib' (no such file), '/usr/local/lib/libffi.7.dylib' (no such 
file), '/usr/lib/libffi.7.dylib' (no such file)Library not loaded: 
/opt/local/lib/libcrypto.1.1.dylib\n  Referenced from: /opt/local/lib/libxar.1.dylib\n  
Reason: tried: '/opt/local/lib/libcrypto.1.1.dylib' (no such file), 
'/usr/local/lib/libcrypto.1.1.dylib' (no such file), '/usr/lib/libcrypto.1.1.dylib' (no 
such file)\nfatal error: /opt/local/bin/otool: fatal error in 
/opt/local/bin/llvm-objdump-mp-10\n"


What provides your /opt/local/libexec/llvm-10/lib/libLLVM.dylib ? Is 
that from brew by any chance? It doesn't look like the Xcode compiler 
path.




Your problem sounds a bit like 
https://stackoverflow.com/questions/71790401/otool-is-referencing-an-old-version-of-libffi




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

Re: [Interest] macdeployqt on Monterey 12.3.1

[Hamish Moffatt via Interest]

On 27/4/22 17:05, Alexander Carôt wrote:
>>That's not guaranteed to work. Major versions 7 and 8 are unlikely 
to be compatible (else they wouldn't have changed the version number 
with all the difficulty that creates).
Agreed, however, the question is if anyone else besides me can 
reproduce the issue so I can file a bug report.

At least the solution works as a temporary workaround for me.


Your error message said

ERROR: "dyld[17429]: Library not loaded: /opt/local/lib/libffi.7.dylib\n  Referenced 
from: /opt/local/libexec/llvm-10/lib/libLLVM.dylib\n  Reason: tried: 
'/opt/local/lib/libffi.7.dylib' (no such file), '/usr/local/lib/libffi.7.dylib' (no such 
file), '/usr/lib/libffi.7.dylib' (no such file)Library not loaded: 
/opt/local/lib/libcrypto.1.1.dylib\n  Referenced from: /opt/local/lib/libxar.1.dylib\n  
Reason: tried: '/opt/local/lib/libcrypto.1.1.dylib' (no such file), 
'/usr/local/lib/libcrypto.1.1.dylib' (no such file), '/usr/lib/libcrypto.1.1.dylib' (no 
such file)\nfatal error: /opt/local/bin/otool: fatal error in 
/opt/local/bin/llvm-objdump-mp-10\n"


What provides your /opt/local/libexec/llvm-10/lib/libLLVM.dylib ? Is 
that from brew by any chance? It doesn't look like the Xcode compiler path.



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

Re: [Interest] macdeployqt on Monterey 12.3.1

[Hamish Moffatt via Interest]

On 26/4/22 15:56, Alexander Carôt wrote:


Thanks for the pointer, however, it looks rather trivial as if it is 
asking for lib versions not existent on Monterey. In order to make it 
workI simply created symbolic links to the current ones:


sudo ln -s libffi.8.dylib libffi.7.dylib

sudo ln -s libcrypto.3.dylib libcrypto.1.1.dylib




That's not guaranteed to work. Major versions 7 and 8 are unlikely to be 
compatible (else they wouldn't have changed the version number with all 
the difficulty that creates).



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

Re: [Interest] qtwebbroser questions

[Hamish Moffatt via Interest]

On 11/4/22 22:52, Alexander Carôt wrote:

Thus, I decided to continue using the minibrowser code which already is Qt6 
ready and worked out fine for me so far. However, here I have the problem that 
it does not store cookies. I did some research and found e.g.

https://stackoverflow.com/questions/19069680/can-you-use-qwebview-cookies-sessions-with-qnetworkaccessmanager

which explains how to set cookies for QWebView but the problem with the example 
code is that QWebView is implemented via QML so the question is how to enable 
cookies this way.



Do you just need to set the persistent cookie policy in QWebEngineProfile?


amish


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

Re: [Interest] qtwebbroser questions

[Hamish Moffatt via Interest]

On 11/4/22 22:52, Alexander Carôt wrote:


Thus, I decided to continue using the minibrowser code which already is Qt6 
ready and worked out fine for me so far. However, here I have the problem that 
it does not store cookies. I did some research and found e.g.

https://stackoverflow.com/questions/19069680/can-you-use-qwebview-cookies-sessions-with-qnetworkaccessmanager

which explains how to set cookies for QWebView but the problem with the example 
code is that QWebView is implemented via QML so the question is how to enable 
cookies this way.



Do you just need to set the persistent cookie policy in QWebEngineProfile?


amish

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

Re: [Interest] can't debug 64bit intel windows app on ARM CPU

[Hamish Moffatt via Interest]

On 26/1/22 05:49, Cristian Adam wrote:


Hi,

Please open a bug report at https://bugreports.qt.io/

Which Windows version are you using? Only Windows 11 has support for 
x64 virtualization for Arm64 machines.




It sounds like a Visual Studio installation issue and nothing to do with 
Qt



Hamish

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

Re: [Interest] SQLite database: avoid high memory usage?

[Hamish Moffatt via Interest]

On 24/1/22 19:40, Alexander Dyagilev wrote:

Hello,

Let's suppose we have a database file of 16GB in size.

We open it using this code:

m_db = QSqlDatabase::addDatabase(
 "QSQLITE",
 dbConnectionName());
m_db.setConnectOptions("PRAGMA jounal_mode=WAL;");
m_db.setDatabaseName(m_dbPath);
m_db.open();

After this, our process will use 16GB of memory (at least, under 
Windows OS). I.e. the whole database file is loaded into the memory.


Is there a way to avoid this? 



Did you mean to misspell journal_mode?

Are you sure it's real memory usage and not just address space used by mmap?


Hamish

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

Re: [Interest] Please let us choose Qt Creator version in the online installer

[Hamish Moffatt via Interest]

On 27/12/21 01:46, Pavel Koshevoy wrote:


Also, the maintenance tool needs to be smart enough not to install an 
incompatible build of Qt Creator on an older version of macos where it 
can't even run.



It would be even better if the installer didn't force you to install 
Creator at all. We don't use it (preferring Visual Studio and Xcode and 
standalone Qt Assistant/Designer), so we don't need it installed.




Hamish

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

Re: [Interest] SSL & Let's Encrypt certificate expiration

[Hamish Moffatt via Interest]

On 7/10/21 02:53, Thiago Macieira wrote:

On Wednesday, 6 October 2021 02:41:39 PDT Hamish Moffatt via Interest wrote:

I upgraded to 1.0.2u and added the X1 root directly to Qt. Now the
application works. But the instructions from OpenSSL say to also remove
the X3 root which I'm not able to do (it's loaded from Windows), so I am
puzzled by why this works. I have not done anything special when
generating my certificates like requesting the alternate certificate chain.

If OpenSSL has any path to a still-valid root certificate, then it can ignore
the others. That's one way of dealing with expirations: you add a new link in
the chain that will continue to be valid when the other path(s) aren't.



The OpenSSL blog writes that this unfortunately doesn't happen with 
1.0.2 though - it sees the expired root and gives up. 
https://www.openssl.org/blog/blog/2021/09/13/LetsEncryptRootCertExpire/



Hamish

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

Re: [Interest] SSL & Let's Encrypt certificate expiration

[Hamish Moffatt via Interest]

On 7/10/21 02:48, Thiago Macieira wrote:

On Tuesday, 5 October 2021 17:03:43 PDT Hamish Moffatt via Interest wrote:

We have had some difficulty here with Windows 10's "lazy loading" of the
root certificates. Unless users have been to a site that uses the ISRG
X1 root certificate using Chrome or Edge, they do not have this
certificate and it is not available to Qt. As soon as they visit a site
that uses the new root in Chrome or Edge, Windows loads the certificate
and it works in Qt.

Interesting. That means there's an API that they're using that causes Windows
to download the certificate, but we don't use it. Can one of you file a bug on
this particular issue on Windows?


Done, QTBUG-97168.


Hamish

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

Re: [Interest] SSL & Let's Encrypt certificate expiration

[Hamish Moffatt via Interest]

On 6/10/21 20:02, Christophe Thomas wrote:
Thank you for the hint, I found this link that talks about it: 
https://community.letsencrypt.org/t/isrg-root-lazy-loading-problem-missing-from-random-updated-windows-10-versions/141550/2 



We've also tested on an old linux (ubuntu 16),

when trying to connect one test website, openssl is not finalizing the 
connection due to expired DST Root X3, and we can see that the chain is

website cert  => ISRG X1 root => DST Root X3

doing the same test with our own software (that uses our own shipped 
lib for openssl) from scratch we fail and we can see we use the same 
chain as above.


Third test still with our software but forcing loading the ca cert 
before first connexion (see first email from maitai => 
def.setCaCertificates(QSslConfiguration::systemCaCertificates());)
In this case we still have the same chain reported, but with DST Root 
X3 expire in 2024 and the connexion is OK


Also on this device, we find the ISRG_Root_X3.pem that is expired.



We still support an old version of our app shipped with Qt 5.8 and 
OpenSSL 1.0.1. This stopped working when the X3 root expired, as expected.


I upgraded to 1.0.2u and added the X1 root directly to Qt. Now the 
application works. But the instructions from OpenSSL say to also remove 
the X3 root which I'm not able to do (it's loaded from Windows), so I am 
puzzled by why this works. I have not done anything special when 
generating my certificates like requesting the alternate certificate chain.



I have Qt 5.15 (OpenSSL 1.1) applications deployed on Debian 10 and have 
not had to do anything to keep that working.



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

Re: [Interest] SSL & Let's Encrypt certificate expiration

[Hamish Moffatt via Interest]

On 6/10/21 06:13, Thiago Macieira wrote:

On Tuesday, 5 October 2021 11:45:23 PDT Christophe Thomas wrote:

For the cert chain we are currently using the default LE setting so we
currently provide the X1 Cross signed with expired X3.

Netherless, the issue is that strangely we need to force caCertificate load
in order to have the connexion accepted.

In the client's system, is the ISRG Root X1 certificate present? Can you check
with plain openssl s_client command to see if the problem is OpenSSL?



We have had some difficulty here with Windows 10's "lazy loading" of the 
root certificates. Unless users have been to a site that uses the ISRG 
X1 root certificate using Chrome or Edge, they do not have this 
certificate and it is not available to Qt. As soon as they visit a site 
that uses the new root in Chrome or Edge, Windows loads the certificate 
and it works in Qt.




Hamish

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

[Interest] QJSEngine won't evaluate octal literal

[Hamish Moffatt via Interest]

I have the following test code to evaluate an octal literal which I'm 
running on Qt 5.12 and 5.15;


            QJSEngine eng;
            auto jsv = eng.evaluate("(function(){return 011;})()");
            qDebug() << jsv.isError() << jsv.toString() << jsv.toVariant();

This outputs:

true "SyntaxError: Expected token `;'" QVariant(QVariantMap, QMap())


It works if I use hex literals, and the octal code works in node.js. Why 
doesn't it work in QJSEngine?



Hamish

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