* 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.11.16, 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. Backported from upstream commit 97688346ada2 (gh-155999). Upstream carries this on 3.12 and newer only; the backport pull request for 3.11 is still open, so this is ahead of upstream - Behaviour change: the "tar" and "data" filters now hand back member names containing ".." in os.path.normpath() form; as upstream notes, removing internal ".." components may change what such a name refers to if it traverses a symbolic link - CVE-2026-19672