Fix PEP706 warning

[pmoravec]

Since Python 3.12, a new warning will be raised in sos/cleaner/archives/__init__.py : archive.extractall(path). The call will emit a warning by default. See https://peps.python.org/pep-0706/ for background / rationale.

To prevent that, we can add something like this before the call:

archive.extraction_filter = getattr(tarfile, 'data_filter',
                                       (lambda member, path: member))

This is compatible with unpatched versions of Python, and for patched Python it is equivalent to the call: archive.extractall(path, filter='data').

The 'data' filter above attempts a "safe" extraction, intended for pure data archives. For example:

• prevents extracting outside the target directory, and to absolute paths (by raising an exception)
• prevents symlinks pointing outside the target directory, and to absolute paths
• adjusts permissions (for the owner, only the executable bit is honored)

See PEP 706 for details: https://peps.python.org/pep-0706/#filters

If we trust the tarball, we should use 'fully_trusted_filter' (or filter='fully_trusted') instead. That will preserve the existing behavior.

I feel we shall stick on the current behaviour (which still means a code change but with fully_trusted_filter attr option) since the extracted archive might(?) break some assumptions (i.e. the symlinks?) imposed to the safe extraction in some use cases - I am afraid using data_filter could end up in raising uncaught warnings in some use cases (or should we be more strict and fix issues behind those use cases, rather?)

[pmoravec]

The more I read about the data filter and think about it, the more I think we should use it. Since an extraction of an "unsafe file" (say, extracting outside directory, or extracting symlinks pointing outside the directory) would mean a bug is sos how it prepared the tarball.

Therefore I would go for data filter rather than for fully_trusted filter - I will prepare a PR for that within a day or two.

Any objections or thoughts, @TurboTurtle , @arif-ali or @mhradile ?

[mhradile]

No objections. Definitely for closing that security hole.

[TurboTurtle]

No objections here.

[arif-ali]

makes sense

[jjansky1]

Can we close this in favor of PR #3330 ?

[TurboTurtle]

Indeed we can.