[3.13] gh-119588: Implement zipfile.Path.is_symlink (zipp 3.19.0). (GH-119591)

[miss-islington]

(cherry picked from commit 42a34dd)

Co-authored-by: Jason R. Coombs jaraco@jaraco.com

• Issue: Implement zipfile.Path.is_symlink #119588

---

📚 Documentation preview 📚: https://cpython-previews--119985.org.readthedocs.build/

[jaraco]

@Yhg1s Can you confirm you consider this issue to be a (security) bug and thus qualifies for merge here and in 3.12?

The bug/security concern is that if a user were to use zipfile.Path().is_symlink() to screen for symlinks thinking that it was actually checking, and then they were to unzip that file using another tool that honor symlinks, they could inadvertently be creating symlinks where they expected not to create them.

It feels slightly more like a feature than a bug fix to me, and I don't feel strongly about it. I'll follow whatever direction you or a delegate wish to go.

[Yhg1s]

No, I do not believe these are important security fixes, and they're changes in behaviour that could just as easily cause security issues. The ZIP standard is much to fluid, what with all its extensions, that you can't mix and match implementations and expect a sensible result. Verifying contents with zipfile and then unpacking with a different tool altogether does not make sense from a security perspective. I believe we should simply consider this a bugfix with a change in semantics. However, I'm okay with this going into 3.13 at this stage, just not 3.12.