Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StreamDecryptor._read_header() fails when source stream does not support tell() and seek() #13

Closed
mattsb42-aws opened this issue Sep 18, 2017 · 1 comment
Assignees
Labels

Comments

@mattsb42-aws
Copy link
Member

StreamDecryptor._read_header() currently assumes that the input stream supports tell() and seek() and uses these methods to rewind the input read after deserializing the header to feed into the header auth hash. If these methods are not supported (ex: for stdin), decryption will fail.

We cannot simply read the entire thing into memory, as we have no way of knowing how large the input stream will be. We cannot use a BufferedReader because we have no way of reasonably knowing how much we need to buffer (somewhere between ~600B and 8MB).

Proposed fix is to create internal.utils.TeeStream, based on internal.utils.ROStream, which will record all data which is read to an alternate stream. This alternate stream will then be read out after reading the header and the contents returned from internal.deserialize.deserialize_header along with the deserialized header.

@mattsb42-aws mattsb42-aws self-assigned this Sep 18, 2017
@mattsb42-aws
Copy link
Member Author

mattsb42-aws commented Sep 19, 2017

In fixing this, I also realized that the single-shot encrypt() and decrypt() calls both resulted in unchecked calls to stream_length, which caused errors in the event of non-seekable input streams. Rolling that fix into this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant