Where did those libraries come from?

[ChoHag]

I have been asked by my employer to install box64 for our developers to use. I do not use it myself.

When doing so I discovered that its build system attempts to install some x86 libraries that it needs. It installs them in a way which could replace the libraries provided by the operating system and the particular libraries which would be installed got me very concerned because they cover network encryption, password validation and DNS resolution, which are highly sensitive, and so I looked in the documentation and git history for where these libraries had been taken from and found nothing.

I understand that a project of this nature might need to include some x86 libraries in order to function but the documentation should say clearly where they come from so that the binary files included in git can be compared with their upstream and sysadmins such as me can be assured that the files are legitimate and don't include some sort of malware.

Please note that I am NOT accusing you of shipping malware. Also the files have been verified by our security team, who have given them a pass.

It's just that the way that these binary files are distributed and installed looks like somebody trying to spread malware.

At the very least I need to know where these binaries come from before I can install them on our systems so that I can verify that they are the same files provided by the upstream vendors. It would also be nice if they weren't blindly installed into /usr/lib.

Ideally I would also like the documentation to explain why these files need to be included at all. Again, it makes perfect sense that some original x86 binaries would be required but the services these particular libraries provide (except PNG) are some of the most security-critical and so just seeing those filenames makes me extremely wary.

In short: Please describe exactly where every binary file in the box64 source repository comes from so that the distributed files can be compared to their originals.

[ksco]

It installs them in a way which could replace the libraries provided by the operating system

Suggest: Let's install it somewhere else to prevent conflicts. E.g. to /usr/lib/box64-x86_64-linux-gnu/ and add this path to the box64 search path.

so I looked in the documentation and git history for where these libraries had been taken from and found nothing.

Agree, it's indeed a good idea to maintain the source for each one of the libraries in the documentation.

[ptitSeb]

Most of the libs comes from debian. They are ere for conveniance and could be ignored with no issue.
I'm fine with moving the libs to a non-standard path to avoid conflict.

Just to explain whay the libs are there (and why they can be ignored): box64 has a mecanism called "Wrappping", that allows x86_64 program to use native library (instead of x86_64 libs). This mecanism is not universal, and only some selected libs (a 100 of libs, roughly) have this mecanism. That means box witl use native version of libc, opengl or openal to run stuffs and you don't need a full x86_64 chroot.
But this wrapping mecanism as some limit. C++ library are not wrapped. That means C++ program, that will certainly needs libstdc++.so and libgcc_s.so will not work without a copy of the x86_64 version. Some other libs, like libunwind.so are architecture dependant, and it make no sense to use the native version. This lib is used by wine. Finaly, so libs are deprecated (libpng12, the olds crypto/ssl version 1.0 and 1.1) and not found anymore in OS. They are wrapped but an x86_64 version is there for convenaince because many linux games still use them (and will probably never be update to newer version).

Again, those library are totaly optional. Use some other version that you provide if you need them, dependaning on what you plan to run.