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
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 2aaf98c16ae3070378de523a173e29644
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 cas
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.
--
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 typ
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
Shashank Agarwal added the comment:
I would like to work on this..
--
nosy: +The_Knight
___
Python tracker
<http://bugs.python.org/issue26296>
___
___
Python-bug
Shashank 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 is that it d
New submission from Shashank :
-- 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 with regard to final state of the
Changes by Shashank :
Added file: http://bugs.python.org/file19495/zipdecrypt.patch
___
Python tracker
<http://bugs.python.org/issue10030>
___
___
Python-bugs-list mailin
Changes by Shashank :
Removed file: http://bugs.python.org/file19494/zipdecrypt.patch
___
Python tracker
<http://bugs.python.org/issue10030>
___
___
Python-bugs-list m
Shashank 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
<http://bugs.python.org/issue10
Shashank 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 in
Changes by Shashank :
Added file: http://bugs.python.org/file19197/zipdecrypt.patch
___
Python tracker
<http://bugs.python.org/issue10030>
___
___
Python-bugs-list mailin
Shashank 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 because the changed class is not
Shashank 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 the already existing tests
New submission from Shashank :
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 in the link above, this can result in
Shashank 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:
--
import cookielib
18 matches
Mail list logo
