Very odd install, possibly malware?

[bill-myers]

It seems the install script here downloads file from a GitLab repository using GitLab API with an ad-hoc GitLab token without providing a link to the GitLab project.

This is an absurd procedure whose only purpose seems to be to obscure the files, since normally those files should be provided in the GitHub project here, or a link to the GitLab project would be provided.

It looks like this might be used to hide malware, i.e. perhaps the mobox author is malicious.

[GuythatUhmCreatesRandomStuff]

It seems the install script here downloads file from a GitLab repository using GitLab API without providing a link to the GitLab project.

This is an absurd procedure whose only purpose seems to be to obscure the files, since normally those files should be provided in the GitHub project here, or a link to the GitLab project would be provided.

It looks like this might be used to hide malware, i.e. perhaps the mobox author is malicious.

He is a trusted developer for stuff like this, dont worry

[bill-myers]

Then why the obscured installation? What's the GitLab repository that holds the actual files? (seems to be private...) Why are they not together with the install script, on GitHub and/or GitLab in a public repository, along with their full sources and build process? (and of course built binary files should be in GitHub releases, definitely not in the repository...)

Even if not malicious, it's hard to read the actual code since one has to run multiple commands from a Linux terminal to get it.

Maybe it's done to reduce the risk of DMCA requests, but it doesn't seem to me an x86/Windows emulator is likely to be susceptible to those since Wine and proton exist just fine for decades.

[bill-myers]

And downloading the files via the GitHub API reveals several tar.xz archives with compiled binaries (including weird original ones like "bin/ib" and "opt/apps/pgup-f6-pgdn-f7.exe" in scripts.tar.xz that is not clear what they do) compiled from who knows what source, with no reproducible build process.

[olegos2]

Aight, I can make .tar.xz packages public, but I don't have build scripts. Ib is input bridge client side binary, made by DotNetBurst without any possibility to get source code. Pgup-whatever.exe is a simple ahk script made into .exe all it does is pressing pgup in wine when f6 is pressed, it is added because input bridge is missing those keys. Some turnip, virgl, wined3d and dxvk are prebuilt drivers. Box64 binaries package contains box64 x86_64 libs and prebuilt box64 binaries, I also provided build instructions for that in some other closed issue. Scripts are mostly bash scripts and some wine executables + registry patches. Wine packages are wine builds built using Kron4Ek repo with some patches, which are provided in mobox github repo. Glibc package is prebuilt glibc packages required to run wine, I took them from termux-pacman/glibc-packages repo

[olegos2]

At first place, I used gitlab because it is available to more users, and sometimes has faster download speeds. And I kept the repo private because there is nothing else, except tarballs of mobox packages and I used it before mobox release, so I didn't want someone to find mobox scripts before release

[BiatuAutMiahn]

@bill-myers, ahk stands for AutoHotKey, its like AutoIt3script but opensource. Its a quick and easy way to write software that compiles to a single portable exe for cases like this. ie; When those hot keys are pressed, something can be done. Wine doesn't already have the functionality so the pgup-f6-pgdn-f7.exe provides it.