[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"
Jami Lindh added the comment: It might also make sense to return the payload undecoded. The documentation for get_payload() function says: "[...] the payload will be decoded if this header’s value is quoted-printable or base64. If some other encoding is used, or Content-Transfer-Encoding header is missing, the payload is returned as-is (undecoded)." Even though the header's value tries to convince you "base64" is the encoding, it is - in this case - either broken base64 or not. Hence it might fall into the category "some other encoding is used", justifying the "payload is returned as-is (undecoded)". As to the original payload Claudiu posted, in that the mailserver has truncated the email. This already provides the user with non-base64 string that they try to convince you to decode as base64. My argument is still valid in this case. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"
Jami Lindh added the comment: Also, I'm not sure what is the development status in Python 3.4 but in my case this bug happened using the Debian Jessie Python version 3.4.2-2 -- versions: +Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"
Jami Lindh added the comment: In my opinion, this is still a clear case of "invalid input, raise an error", but I don't think AssertionError is the right one. Maybe just don't catch the unexpected binascii.Error and let it fly towards the user? I might go even one step further and just let base64 library handle and raise all the necessary errors here, similarly to how your "encode_b" function works. If you want more error resilience (meaning: email lib would not crash with invalid inputs), I would think returning an empty string is okay, since that base64 input is clearly not a valid base64 that is going to decode into anything. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"
Jami Lindh added the comment: I stumbled upon this bug as well while fuzzing with AFL. The curious thing is that email.message_from_string still accepts that garbled message as a valid email. -- nosy: +CryptidVulpes versions: +Python 3.4 Added file: http://bugs.python.org/file43921/issue27397_poc.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27397] email.message.Message.get_payload(decode=True) raises AssertionError that "should never happen"
Jami Lindh added the comment: I also attached a minimal script containing only the decode call and the garbage payload. -- Added file: http://bugs.python.org/file43922/issue27397_poc_minimal.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
