Seeking back beyond the decrypted / unzipped buffer doesn't reset the decrypter's crc key values. All data read after seeking back beyond the buffer is garbled.

Hi, I have another patch I would like to contribute to the zipfile module but would like to request a review of this one to minimise conflicts with later patches. If anyone is able to review the patch, I would really appreciate it :) Also, with regards to selecting Python versions for this issue, is there any rule of thumb I should be following? Thanks, Dan

PR 16937 is simpler. It does not change the decrypter.

Thanks for looking at the PR. I got carried away refactoring the decrypter for a future scenario where there could be different decrypters (possibly using certificates too) :) Your PR is much simpler. Would you also be able to take a look at some other PRs I've submitted for zipfile. They are both pretty small changes: https://bugs.python.org/issue36993 https://bugs.python.org/issue37523 Thanks again, Dan

I also think that the `read_init` method in my PR is a useful refactor as it locates all the state that needs to be (re)set when starting a read into the same location. At the moment this state is set in 1) __init__ and 2) the seek method when seeking back beyond what is in the buffer.

 New changeset 5c32af7522d908e8c7da0243af37618433289cc5 by Serhiy Storchaka in branch 'master': bpo-38334: Fix seeking backward on an encrypted zipfile.ZipExtFile. (GH-16937) https://github.com/python/cpython/commit/5c32af7522d908e8c7da0243af37618433289cc5 

 New changeset 76fbdaa2a693caaa1b8eb34104720fc774ff80df by Miss Skeleton (bot) in branch '3.8': bpo-38334: Fix seeking backward on an encrypted zipfile.ZipExtFile. (GH-16937) https://github.com/python/cpython/commit/76fbdaa2a693caaa1b8eb34104720fc774ff80df 

 New changeset ed2db3113d54a5f8af1b419a9f5fdf3642285c82 by Miss Skeleton (bot) in branch '3.7': bpo-38334: Fix seeking backward on an encrypted zipfile.ZipExtFile. (GH-16937) https://github.com/python/cpython/commit/ed2db3113d54a5f8af1b419a9f5fdf3642285c82 

> I got carried away refactoring the decrypter for a future scenario where there could be different decrypters (possibly using certificates too) :) The decrypter was implemented with a generator for performance. The performance of decrypting is not critical, but this got us 2x speed up without complicating the code. See issue10030. If the support of other decrypters be added, they will likely be implemented in C in any case. > I also think that the `read_init` method in my PR is a useful refactor as it locates all the state that needs to be (re)set when starting a read into the same location. This is a different issue. > Would you also be able to take a look at some other PRs I've submitted for zipfile. Thank you, they look good to me. I left just few comments. As for the original issue, I have doubts that backward seeking in a compressed file is a good idea. But this feature was added, and it worked with encrypted files if seek in the range of the buffer, so not working out of the range of the buffer is a bug which we should fix.

Thanks for your help! Good point, I'll create a new change for the refactoring.