Magicpak: Build minimal Docker images without static linking
github.com
github.com
But I guess it's useful if you already have an ad-hoc build system and you can't/won't migrate to something industrial-strength.
The original commenter called magicpak a 'cool alternative to nix', to which I replied that nix is an industrial-strength, tested and very through solution, while magicpak is more like a dirty hack. (We used to have an internal tool much like magicpak before nix came along.)
You can make a smaller tar file by including just the static file (less inodes/wasted file space of deps linking to each other/unnecessary extra function call data). And technically static files can sometimes execute faster (depending on page/cpu cache etc). But the advantages of static are much smaller when you consider the advantages to dynamic in a tar file - and even more advantages in a container.
So while there can be advantageous, they are vanishingly small.
OTOH, container images seem to be bloated by unused binaries and completely unused libraries, not unused functions in shared libraries.
Here are some possible advantages I can think of: less surface area for security, less surface area for maintenance, smaller container image, implying faster time to pull image, and perhaps also faster time to boot image.
Disadvantages: you have to do the work to set it up in the first place and maintain it (putting in extra effort to avoid adding superfluous dependencies in future), while the above advantages may be marginal.
This might also be true if you simply copy shared libraries. AFAICT these scanners rely on the package index to identify potential CVE exploits. But I may be wrong, and in any event it'd be much more difficult to identify the version of a statically linked library than a shared library, which can be identified by its name or hash.
This doesn't excuse avoiding keeping containers updated, but if you want to be cynical about vulnerability management, i.e. that any trick which improves the signal-to-noise ratio is worth exploring, then it's something to keep in mind.
BTW IIRC normal static linking doesn't strip out all unused functions, you need LTO (Link Time Optimisation) to do that.
LTO does something more complex than just pick the right routines - it does the last few compilation/optimization stages when you run the linker. As a result, you get to inline across modules, drop some unused functions and more - however, this would only work for object files that were properly LTO compiled themselves. If you have e.g. a third party library that wasn’t LTO compiled for your specific tool chain, you are back to the “whole object file or bust” link regime.
https://github.com/facebookincubator/BOLT https://www.phoronix.com/scan.php?page=news_item&px=Google-P...
The only edge case I can think of is if you could use it for ROPing some gadgets from the unused functions, but that's pretty unlikely and the gadgets are usually not that unique.
Most advantages are in performance: smaller size, faster loading, better cache usage.
Shared libraries, at least, allow more automated updates, but containers are still a problem.
I did this just recently by hand when I wanted to run a source-only binary in my dom0 but didn't want to build it in the dom0. I built it in a container, checked what shared libraries it wanted with `ldd path/to/binary` inside the container, copied all of the referenced libraries to ~/libs, then copied that dir and the binary to dom0 and ran it with `LD_LIBARARY_PATH=$HOME/libs path/to/binary`, worked perfectly.
The 5 W's[1] aren't just for journalists.
It’s a lock on the door - keeps honest people honest and erroneous rm -rf confined. But it might not stop a determined hacker.
BTW: I might be an exceptional person. But the first thing I look for in a new software is how it works. Granted that, in most cases, I might not be the targeted audience. But a brief introduction can effectively boost my interests in learning more. The opposite case, i.e., no such information, turns off my curiosity.