)]}'
{"glance_store/_drivers/swift/store.py":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"4063053a59d48c175ac7cc4580ceab0544ed52df","unresolved":false,"context_lines":[{"line_number":1633,"context_line":""},{"line_number":1634,"context_line":"        result \u003d self.do_read(i)"},{"line_number":1635,"context_line":"        if not isinstance(result, bytes):"},{"line_number":1636,"context_line":"            result \u003d result.encode(\u0027utf-8\u0027)"},{"line_number":1637,"context_line":"        self.bytes_read +\u003d len(result)"},{"line_number":1638,"context_line":"        self.checksum.update(result)"},{"line_number":1639,"context_line":"        self.os_hash_value.update(result)"}],"source_content_type":"text/x-python","patch_set":2,"id":"9fdfeff1_51c8e372","line":1636,"updated":"2019-02-23 03:44:29.000000000","message":"I think there is a good chance that this is incorrect.  Here is why.  Any bytes in range(128,256) will become two bytes when encoded as utf-8.  The checksum and os_hash_value objects will be happy because we are handing them bytes, but how do we know that these are the correct bytes?  Without a better understanding of why \u0027result\u0027 is no longer of the \u0027bytes\u0027 type, I think there\u0027s a good chance we will wind up with corrupted data--although no one will know until they try to use the image, because the size, checksum, and os_hash_value that will be stored as image properties will be those of the *corrupted* data, not those of the original data.  (In other words, they will be correct for what is actually stored in glance, but will not match the uploaded data.)","commit_id":"038ffd03d5d74fd853c6619a1f860b45e9519ff6"},{"author":{"_account_id":15343,"name":"Tim Burke","email":"tburke@nvidia.com","username":"tburke"},"change_message_id":"f1ee13727a750f1139bcfb581cdc2e9d7c87cf4b","unresolved":false,"context_lines":[{"line_number":1641,"context_line":"        if i \u003d\u003d 0:"},{"line_number":1642,"context_line":"            result \u003d b\u0027\u0027"},{"line_number":1643,"context_line":"        else:"},{"line_number":1644,"context_line":"            result \u003d self.do_read(i)"},{"line_number":1645,"context_line":""},{"line_number":1646,"context_line":"        self.bytes_read +\u003d len(result)"},{"line_number":1647,"context_line":"        self.checksum.update(result)"}],"source_content_type":"text/x-python","patch_set":5,"id":"5fc1f717_5c9ef263","line":1644,"updated":"2019-03-07 20:27:02.000000000","message":"I\u0027ve still got this nagging feeling like we\u0027re treating the symptom and not the cause. ChunkReader expects that the fd passed in during initialization be a file-like opened in binary mode -- so why is fd.read() returning something other than a byte string? What type is fd, and if it\u0027s some reasonably thin wrapper around *another* file-like, what\u0027s *that* one doing? Keep following the chain until we figure out what\u0027s introducing a native string.\n\nFWIW I found https://review.openstack.org/#/c/641525/ yesterday; maybe that\u0027s part of the story?\n\nI understand that we\u0027ve got a bug and it\u0027s appealing to fix the bug now and address root causes later... but even then I might go with something like\n\n result \u003d self.do_read(i)\n if not result:\n     result \u003d b\u0027\u0027\n\nin case someone tried to do a *non-zero* read and the file-like still returned an empty (native) string.","commit_id":"229b41baa441615af9d5af4df58e953eecfdec49"}]}