[issue18595] zipfile: symlinks etc.

Changes by Thomas Kluyver : -- nosy: +takluyver ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.py

[issue18595] zipfile: symlinks etc.

Xavier Combelle added the comment: about the readlink functionnality, I would like to point that it might lead to security issues see for example https://security.stackexchange.com/questions/73718/how-zip-symlink-works At least, the standard read should not do it by default. -- nosy:

[issue18595] zipfile: symlinks etc.

Changes by Serhiy Storchaka : -- versions: +Python 3.5 -Python 3.4 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscrib

[issue18595] zipfile: symlinks etc.

Serhiy Storchaka added the comment: > * "read" will raise an exception when trying to read a symlink > (alternative: do symlink resolving, but that's too magical to my taste) And perhaps when trying to read a directory entry too. > * "extract" and "extractall" extract the symlink as a symlink

[issue18595] zipfile: symlinks etc.

Ronald Oussoren added the comment: My initial plan was to add the patch soon after filing the issue, but that's before I noticed that this needs some API design to integrate nicely :-) My current idea for the api: * add "symlink(path, target") to write a symlink * add "readlink(path)" to read

[issue18595] zipfile: symlinks etc.

Jesús Cea Avión added the comment: Ronald, could you try to write a patch? -- nosy: +jcea stage: test needed -> needs patch ___ Python tracker ___ ___

[issue18595] zipfile: symlinks etc.

New submission from Ronald Oussoren: The zipfile format (as described by .zip file format specification) allows for storing extra unix data, such as symlinks and device nodes in zipfile. Storing at least symlinks would be useful, and is supported by the infozip tools as well (the command-line