* SECURITY UPDATE: tarfile ignored a custom extraction filter that skips a member on the hard-link fallback path - debian/patches/CVE-2026-87910.patch: keep the result of the first filter_function() call in makelink_with_filter() and return when it is None. When extracting a hard link falls back to extracting the target member under the link's own name, the CVE-2026-11940 guard re-runs the filter with that substituted name, but only an exception was acted upon. A PEP 706 custom filter signals "skip this member" by returning None rather than raising, so such a filter was silently ignored on this path and the member was extracted anyway, under the very name the filter had just refused. Also carries upstream's test_extract_filters_target_none regression test and the matching adjustment to test_sneaky_hardlink_fallback. The guard being repaired is native to the shipped upstream micro 3.10.21, not a patch of ours - CVE-2026-87910 * SECURITY UPDATE: tarfile tar/data filters created directories outside the destination for a member name that leaves it and returns - debian/patches/CVE-2026-19672.patch: normalise a member name containing a ".." component in _get_filtered_attrs() before the containment check. The check looks at the resolved path, which stays inside the destination for a name such as "../evil/../dest/sub/file", while the intermediate directories are created from the name as given, so "evil" was created as a sibling of the destination directory. POSIX only. Also carries upstream's test_parent_dir_out_and_back regression test, as merged. Backported from upstream commit 97688346 (gh-155999, GH-156000). Behaviour change: the "tar" and "data" filters now rewrite such a member name with os.path.normpath(), which drops internal ".." components and so may change the meaning of a name that traverses symbolic links. Upstream carries this on 3.12 and newer only; the backport pull request for 3.10 is still open, so this is ahead of upstream - CVE-2026-19672