Build Sandboxie-Plus with Qt 5.15.13 (L)GPL instead of 5.15.2

[LumitoLuma]

Sandboxie-Plus uses Qt 5.15.2 for some of its UI and software components. That Qt version is from ~4 years ago, and it may have software and/or security issues that were fixed in the following releases. Qt states that they have solved >1000 bugs and/or security issues since 5.15.2.

Qt releases the source code of its LTS builds like one year after they get pushed to the commercial branch. On March 8, Qt open sourced release 5.15.13. I have fully compiled that release (in release mode ― not debug) for Windows x64 and x86, and modified SBIE Plus' build scripts to use those builds instead.

After some testing on both x64 and x86 releases, no new bugs were found. Qt ARM64 builds are left intact.

Note: my own Qt builds have no modified or additional source code, and have been downloaded directly from Qt's website (https://download.qt.io/official_releases/qt/5.15/5.15.13/single/qt-everywhere-opensource-src-5.15.13.zip). They have been configured with the -release -opensource flags.

[DavidXanatos]

So you are in charge of https://qt-opensource-lts-builds.s3.amazonaws.com/ ???
Using newer QT would be good, but I think, but we need to ensure that self compiled qt binaries cant be easily manipulated, is the build process reproducible?
Best would be to use a CI mechanism to auto build the preset Qt soruces downloaded directly from Qt's servers then we could pull these artifacts autoamtically in the sbie CI run

[LumitoLuma]

So you are in charge of https://qt-opensource-lts-builds.s3.amazonaws.com/ ??? Using newer QT would be good, but I think, but we need to ensure that self compiled qt binaries cant be easily manipulated, is the build process reproducible? Best would be to use a CI mechanism to auto build the preset Qt soruces downloaded directly from Qt's servers then we could pull these artifacts autoamtically in the sbie CI run

Yes, but I have updated the build script since. Now:

• It downloads through a GitHub release page (https://github.com/LumitoLuma/qt-opensource-lts-builds/releases) instead of an S3 bucket.
• The install_qt.cmd script has the SHA256 checksum of the downloaded files, and verifies them before compiling.

I have updated today the Qt binaries to apply (official) patches for 10 security vulnerabilities. More details below. Patched source code is available here: https://github.com/LumitoLuma/qt-opensource-lts-builds/releases/download/v5.15.13-lgpl/qt-everywhere-opensource-src-5.15.13-patched.zip

My builds are reproducible, but they take a lot of time even on good hardware. On a 5900X with 32GB of RAM, builds take more than three hours each (there are two builds, x64 and x86), so building with GH Actions will take probably a day or so, without taking into account the time needed to prepare the actions script. Note that I also build QtWebEngine, which is not used for this project, so removing it will speed builds up a lot.

They also require downloading a bunch of tools from multiple websites, and setting up a good build env. x64 and x86 require different build envs.

Nevertheless, the build steps are:

1. Install VS2019 build tools with ATL and Win10 SDK 10.0.19041 (remove any newer versions, if possible).
2. Install Python2, nodejs 12, clang 6.0.1 (from LLVM's website) and perl.
3. Download jom for faster builds.
4. Install git bash, msys2 or patch tool for patching source code.
5. Download source code from Qt's website (https://download.qt.io/official_releases/qt/5.15/).
6. Download security patches:

• CVE-2023-32573 (CVE-2023-32573-qtsvg-5.15.diff)
• CVE-2023-32762 (CVE-2023-32762-qtbase-5.15.diff)
• CVE-2023-32763 (CVE-2023-32763-qtbase-5.15.diff)
• CVE-2023-33285 (CVE-2023-33285-qtbase-5.15.diff)
• CVE-2023-34410 (CVE-2023-34410-qtbase-5.15.diff)
• CVE-2023-37369 (CVE-2023-37369-qtbase-5.15.diff)
• CVE-2023-38197 (CVE-2023-38197-qtbase-5.15.diff)
• CVE-2023-43114 (CVE-2023-43114-5.15.patch)
• CVE-2023-51714 (0001-CVE-2023-51714-qtbase-5.15.diff & 0002-CVE-2023-51714-qtbase-5.15.diff)
• CVE-2024-25580 (CVE-2024-25580-qtbase-5.15.diff)

7. Place them in the right location, and run patch -p1 -i file for each of them.
8. Enter x64 vs build env (or x64_x86 for x86 builds).
9. Add all the build tools to PATH, and set LLVM_INSTALL_DIR to the root of your LLVM installation dir.
10. Add the gnuwin32\bin path from Qt's source to PATH.
11. Run configure.bat -debug-and-release -opensource -nomake examples.
12. Run jom.
13. Run jom install.
14. The built binaries should be located at C:\Qt\Qt-5.15.13, remove all the .pdb files and move the build files to a 5.15.13\msvc2019(_64) folder.
15. Copy libclang.dll from clang's dir to the bin folder, for qdoc to work.
16. Compress into 7z and upload artifact.
17. Repeat the previous steps for the other build (remember to download clang for the other architecture).

You also have SBIE build artifacts available here: https://github.com/LumitoLuma/Sandboxie/actions/runs/8315103110.

[isaak654]

I have just merged all commits into one and removed an outdated test file, I hope this will help in the review process.

[DavidXanatos]

I talked to my friend responsible for signing of sandboxie and a binary dependency on a repository without existing reputation is not something we feel comfortable with.

If the entire process can be scripted such that its transparent and can be run with no extra steps on a clean windows 10 VM then we can create our own build which we can use.

[LumitoLuma]

I talked to my friend responsible for signing of sandboxie and a binary dependency on a repository without existing reputation is not something we feel comfortable with.

I understand.

If the entire process can be scripted such that its transparent and can be run with no extra steps on a clean windows 10 VM then we can create our own build which we can use.

I think that if components like qdoc and qtwebengine are not needed, automation could be done without many issues.

Will attempt to make a script asap.

[isaak654]

According to this comment, OpenSSL 3 is supported with Qt 5.15.13, so if this is indeed the case, I would suggest to open a new pull request to update get_openssl.cmd which is currently based on OpenSSL 1.1.1p (EOL).

[LumitoLuma]

@DavidXanatos, I have successfully created a GitHub actions build script that builds Qt 5.15.13 from official source with official patches. Take a look here: https://github.com/LumitoLuma/qt-builds. You can fork it, but take into account that you must provide a short name for the repo (like qt-builds), else the build might fail due to Windows Path length issues. After the fork, you'll need to run the Build Qt 5.15 action manually. It takes about an hour to build.

An action has already successfully run: https://github.com/LumitoLuma/qt-builds/actions/runs/8426199355, with detailed build logs available. Archives contain the 7z file which contains the compiled binaries.

You could also build it by yourself on a Windows 10 VM. You just need to have VS 2019 Enterprise installed (you can also use build tools or whatever edition, just update build_sources.cmd with the desired edition) with Win10SDK 10.0.19041.1 for the build tools, chocolatey to install GNU patch, required to apply the security patches provided by Qt, and 7-zip. After that, clone the repo to a location with a short path (like C:\qt-builds) and open a cmd as admin. Run:

1. download_sources.cmd
2. install_jom.cmd
3. build_sources.cmd x64 (or Win32 for x86 build)

Then you should have a compressed 7z file in the archive dir. Remember to fully clear your dev directory before building for another architecture.

If you upload the builds to a specific location, let me know to update the SBIE build script.

[DavidXanatos]

Great that was quick, and it only takes 1h to build, perfect :D
So its without QtWebEngine, for now we don't need it, but may in future, would it be a lot of extra work to add this?
I forked the repos and let it run: https://github.com/xanasoft/qt-builds/ once done I'll upload the artifacts as a release there and we can update the build script accordingly.

[DavidXanatos]

Now that I think about it, could you update the script to re pack the patched sources and upload as an artifact,
not sure if that's needed but Qt always emphasizes that if some one has own builds it their obligations to provide the sources, so while pointing to qt's own downloads probably is enough having a patched source archive in the releases page would be ideal.

[LumitoLuma]

Now that I think about it, could you update the script to re pack the patched sources and upload as an artifact, not sure if that's needed but Qt always emphasizes that if some one has own builds it their obligations to provide the sources, so while pointing to qt's own downloads probably is enough having a patched source archive in the releases page would be ideal.

@DavidXanatos, I have updated the build scripts, and should provide an artifact which contains the patched Qt source per action run. Since the patched source is the same for all 5.15.13 builds, you can just use mine: https://github.com/LumitoLuma/qt-builds/actions/runs/8434660874/artifacts/1358901053.

Take into account that, to not abuse GitHub Actions, these artifacts (Qt patched sources) will last only 5 days, so download them asap and then upload the artifacts to the corresponding releases.

So its without QtWebEngine, for now we don't need it, but may in future, would it be a lot of extra work to add this?

No really, it would just require to add the specific tools needed (I think python2 and maybe perl and clang), but build will take like 3-4 hours more, I think. So I think it will be a waste of time to build it if we don't need it, and the script could be updated when required.

[DavidXanatos]

Great, i have merged the pull request and updated it to use our build, thanks again :)

[PARAViRTUALiZATiON]

Maybe this is also interesting in this Qt-Ui-Context:

Qt⁶ | Windows⁷
(currently Qt 6.6.3)

[DavidXanatos]

Maybe this is also interesting in this Qt-Ui-Context:

Qt⁶ | Windows⁷ (currently Qt 6.6.3)

I would like that a lot, if @LumitoLuma would have time to create a build script and everything works reliably that would be great windows 7 holds a strong 3% of the market share so it would be really nice to be able to use newest Qt on a public build

[isaak654]

An update could certainly be done for the ARM64 build, which is currently rather behind with the latest version of Qt.

If there are plans to adopt Qt 6 for all platforms, that wouldn't be a bad thing, as long as there is thorough testing in this regard.

[DavidXanatos]

well plans it depends.... MSFT is probably soon releasing windows server 2025 and with that github will retire the server 2019 workers with visual studio 2019, later workers with visual studio 2022 can not compile windows 7 compatible drivers, soooo... at some point windows 7 support will be problematic.
So if we don't find a workaround for win 7 we may need to drop 7 support at which point we can just use qt stock 6.x as is, that said until then it would still be nice to try a broad qt6 deployment.