shashank added the comment:
It won't exactly be drop-in replacement.
I mean if users decide to replace Tarfile with SafeTarFile, existing code may
break since there might be cases where dodgy tarballs are acceptable and/or
used then SafeTarFile.open will throw an exception.
Having said
shashank added the comment:
Added tests.
Patch file: safetarfile-4.diff
Following works with 456 tests passed, after doing `make clean && make`
# ./python -m unittest -v test.test_tarfile
Attached patch is on top of master's commit:
commit 2aaf98c16ae3070378de523a173e29644037d8
shashank added the comment:
I can't use Jakub's repo (or Makefile from that repo) directly because it
relies on tar, which doesn't look like dependency for building Python. I can
make similar tarballs but I am not sure how licensing will work. I can add
tarballs for the cases I discovered
shashank added the comment:
Figured a fix for the bug I found, trick was to keep track of current working
dir of symlink it was trying to evaluate.
Attached patch: safetarfile-3.diff
Patch is for code only.
I'd like to see this go thorough, and would appreciate feedback.
--
Added
shashank added the comment:
1. I have done some changes to Lar's patch to address class of bugs which Jakub
found.
Attached patch safetarfile-2.diff
Patch is for code only and is work in progress.
2. However, there maybe several edge cases which have not been covered. Going
by types
shashank added the comment:
A. Regrading Jakub's tests, I suppose the changes needed are to
for every name in tar
i) find reasonable occurrence of symlink's name and replace it with smylink's
linkname
ii) convert it to normal path and then check for relative / absolute paths
B. Jakub
Shashank Agarwal added the comment:
I would like to work on this..
--
nosy: +The_Knight
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Shashank shashank.sunny.si...@gmail.com:
-- Converting the discussion here
http://mail.python.org/pipermail/python-list/2010-November/1259601.html to a
bug report (+nosy for everyone that responded, quoting the initial message for
context)
Are there any promises made
Shashank shashank.sunny.si...@gmail.com added the comment:
@Raymond: I don't have a particular use case where I had a problem with this
behavior. I came across this problem when looking at this issue
http://bugs.python.org/issue6305.
An important problem that can happen with this behavior
Shashank shashank.sunny.si...@gmail.com added the comment:
I had uploaded an incorrect patch. New corrected patch against trunk (on Mac OS
uploaded).
--
Added file: http://bugs.python.org/file19494/zipdecrypt.patch
___
Python tracker rep
Changes by Shashank shashank.sunny.si...@gmail.com:
Removed file: http://bugs.python.org/file19494/zipdecrypt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10030
Changes by Shashank shashank.sunny.si...@gmail.com:
Added file: http://bugs.python.org/file19495/zipdecrypt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10030
Shashank shashank.sunny.si...@gmail.com added the comment:
the C module should be private and therefore called _zipdecrypt
done
if you want to avoid API mismatch, you could give a tp_call to your C
decrypter object, rather than a decrypt method
done
- you can put all initialization code
Shashank shashank.sunny.si...@gmail.com added the comment:
Attached is a patch with changes in Lib/test/test_zipfile.py to test both C and
pure-py impls (on systems where the C impl is present).
Admittedly, this approach to emulating the absence of C impl is a bit hacky.
This is primarily
Changes by Shashank shashank.sunny.si...@gmail.com:
Added file: http://bugs.python.org/file19197/zipdecrypt.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10030
Shashank shashank.sunny.si...@gmail.com added the comment:
I have updated the patch with a check for the availability of C impl and to use
pure-py impl as a fallback.
How do you suggest would the tests change? As I had mentioned before, in my
understanding since there is no change in the API
New submission from Shashank shashank.sunny.si...@gmail.com:
As promised in this thread
http://mail.python.org/pipermail/python-dev/2009-August/091450.html (a year
ago!), attached is a patch that replaces simple zip decryption logic written in
pure python with that in C.
As reported
Shashank shashank.sunny.si...@gmail.com added the comment:
Works fine for me in 2.6 but fails as said by OP on 2.5.
(I came across this in the course of my work and am submitting a change
in a bug for the first time, pardon me if something is inappropriate :)
I used this modified codeblock
18 matches
Mail list logo
