Document inability to extract symbolic links from ZIP files

[amyspark]

Describe the bug

Meson currently relies on shutil.unpack_archive to decompress binary wraps. This in turn relies on tarfile and zipfile to do the heavy lifting.

However, security implications aside, there's an undocumented catch: tarfile can extract symbolic links while zipfile can not.

While it's a Python limitation in that they do not support the relevant feature, this should be worked around or at least documented for sanity reasons.

To Reproduce

The following reproduces it indirectly, through a failure to find an existing library in a binary wrap.

meson.build:

project('test', 'c')

x = dependency('optimfrog-osx-x64', required: true)

subprojects/optimfrog-osx-x64.wrap

[wrap-file]
directory = OptimFROG_OSX_x64_5100
source_url = http://losslessaudio.org/Downloads/A1C0/5100/OSX/OptimFROG_OSX_x64_5100.zip
source_filename = OptimFROG_OSX_x64_5100.zip
source_hash = cf0660c7d4329c676434d3c689eb7f13d3d94d7716d79304aa2305c50f2b57c8
patch_directory = optimfrog-OSX-x64

subprojects/packagefiles/optimfrog-osx-x64/meson.build:

project('OptimFROG_OSX_x64_5100', 'c', license: 'http://losslessaudio.org/License.php')

if target_machine.system() == 'darwin' and target_machine.cpu_family() == 'x86_64'
	compiler = meson.get_compiler('c')

	optimfrog_dep = declare_dependency(
		dependencies : compiler.find_library('OptimFROG', dirs : meson.current_source_dir() / 'SDK' / 'Library'),
		include_directories : include_directories('SDK')
	)

	install_data(
		'SDK/Library/libOptimFROG.0.dylib',
		install_dir: get_option('libdir')
	)

	install_symlink(
		'libOptimFROG.dylib',
		install_dir: get_option('libdir'),
		pointing_to: 'libOptimFROG.0.dylib'
	)

	meson.override_dependency('optimfrog', optimfrog_dep)
endif

Expected behavior

The lookup should succeed due to lipo following the symlink.

system parameters

• Is this a cross build or just a plain native build (for the same computer) Native
• what operating system (e.g. MacOS Catalina, Windows 10, CentOS 8.0, Ubuntu 18.04, etc.) MacOS Big Sur 11.7.4
• what Python version are you using e.g. 3.8.0 3.11.2
• what meson --version 1.0.1
• what ninja --version if it's a Ninja build 1.11.1

[eli-schwartz]

However, security implications aside, there's an undocumented catch

Sure, and if/when CPython adds an option to disable symlinks Meson should probably pass the policy to indicate that this is a trusted/checksummed context. (Actually, it is trusted and we don't care, but setting the "tar" policy rather than the one cpython might use, which is "data", is also fine. I am pretty sure we do NOT want "data", as that's quite restrictive in ways that could break reasonable use of meson's install_data etc. functionality.)

While it's a Python limitation in that they do not support the relevant feature, this should be worked around or at least documented for sanity reasons.

The non-standard nature of the feature is a bit awkward. :D I don't think it makes much sense to work around this in meson -- what would a workaround look like, exactly? the standard library is the only unzip tool we have available and we're not shelling out to one that doesn't exist -- but documenting it is certainly an option.