Skip to content

set_payload does not handle binary payloads correctly #62524

Closed

Description

@bitdancer
BPO 18324
Nosy @warsaw, @bitdancer, @vajrasky
Files
  • set_qp_payload_test.patch
  • set_payload_handles_binary_correctly.txt: Makes the set_payload handles binary correctly
  • set_payload_binary.txt
  • set_payload_binary_v2.txt
  • set_payload_binary_v3.txt
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2013-08-22.01:18:56.039>
    created_at = <Date 2013-06-28.19:16:22.263>
    labels = ['easy', 'type-bug', 'expert-email']
    title = 'set_payload does not handle binary payloads correctly'
    updated_at = <Date 2013-08-22.01:18:56.037>
    user = 'https://github.com/bitdancer'

    bugs.python.org fields:

    activity = <Date 2013-08-22.01:18:56.037>
    actor = 'r.david.murray'
    assignee = 'none'
    closed = True
    closed_date = <Date 2013-08-22.01:18:56.039>
    closer = 'r.david.murray'
    components = ['email']
    creation = <Date 2013-06-28.19:16:22.263>
    creator = 'r.david.murray'
    dependencies = []
    files = ['30726', '30884', '30998', '31000', '31049']
    hgrepos = []
    issue_num = 18324
    keywords = ['patch', 'easy']
    message_count = 13.0
    messages = ['192012', '192823', '192826', '192828', '192829', '193454', '193455', '193456', '193490', '193493', '193771', '195850', '195853']
    nosy_count = 4.0
    nosy_names = ['barry', 'r.david.murray', 'python-dev', 'vajrasky']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue18324'
    versions = ['Python 3.3', 'Python 3.4']

    Activity

    1. bitdancer commented on Jun 28, 2013

      @bitdancer
      MemberAuthor

      In order to maintain model consistency without exposing the need for 'surrogateescape' to library users, it should be possible to pass binary data to set_payload and have it do the correct conversion to the expected storage format for the model. Currently, this does not work. The attached patch provides one example test out of a class of tests that should be written and made to pass.

    2. vajrasky commented on Jul 10, 2013

      vajraskymannequin
      Mannequin

      Here is the preliminary patch for email module to pass the test.

    3. bitdancer commented on Jul 10, 2013

      @bitdancer
      MemberAuthor

      Thanks, but the patch is incorrect. The model consistently stores its data as surrogateescaped strings, and this assumption is baked in to other parts of the code. So the correct fix is to do the surrogateescape encoding at the time the payload is set.

      It might in fact be better to store a binary payload as binary, but making that kind of change to the model requires much more extensive review and testing.

    4. vajrasky commented on Jul 10, 2013

      vajraskymannequin
      Mannequin

      I see. Thanks for the explanation. I'll do this patch if nobody is interested.

    5. bitdancer commented on Jul 10, 2013

      @bitdancer
      MemberAuthor

      If you want to work on it that would be great. Note that one of the things that is needed is a bunch more tests of setting various *kinds* of binary payload, including ones containing non-ascii data, and making sure the right thing happens when the payload is later fetched/serialized.

    6. vajrasky commented on Jul 21, 2013

      vajraskymannequin
      Mannequin

      Here is the patch for this ticket.

      David Murray, am I on the right path? If yes, I'll put more robust tests, such as the ones with Asian encodings and unusual encodings.

    7. vajrasky commented on Jul 21, 2013

      vajraskymannequin
      Mannequin

      Sorry, got typo for the last patch.

    8. bitdancer commented on Jul 21, 2013

      @bitdancer
      MemberAuthor

      It looks like you are still patching get_payload. This should be a really simple patch against set_payload.

      It occurs to me that there could be a backward compatibility concern if passing binary to set_payload currently actually works in some cases, so we definitely needs a bunch of test that do that to make sure they all fail before we fix the bug :)

    9. vajrasky commented on Jul 22, 2013

      vajraskymannequin
      Mannequin

      "It looks like you are still patching get_payload. This should be a really simple patch against set_payload."

      Okay, do I get it right at this time?

      About your second point, I need more time to think about it.

    10. bitdancer commented on Jul 22, 2013

      @bitdancer
      MemberAuthor

      Yes, that's what I had in mind.

    11. vajrasky commented on Jul 27, 2013

      vajraskymannequin
      Mannequin

      Here is the third version of the patch.

      I am not sure what to do with the invalid data for base64 and uuencode. I decided to raise exception instead of converting it to None silently.

    12. python-dev commented on Aug 22, 2013

      python-devmannequin
      Mannequin

      New changeset 64e004737837 by R David Murray in branch '3.3':
      bpo-18324: set_payload now correctly handles binary input.
      http://hg.python.org/cpython/rev/64e004737837

      New changeset a4afcf93ef7b by R David Murray in branch 'default':
      Merge bpo-18324: set_payload now correctly handles binary input.
      http://hg.python.org/cpython/rev/a4afcf93ef7b

    13. bitdancer commented on Aug 22, 2013

      @bitdancer
      MemberAuthor

      Thanks, Vajrasky. The v2 patch was almost correct. What you couldn't know without being as deeply enmeshed in this code as I am is that the test failures from the encoders module were actually invalid. We'd previously "fixed" them, but the fixes were incorrectly compensating for this bug in set_payload. Once this bug was fixed, those "fixes" just needed to be backed out, a 'decode=True' added to their get_payload calls, and all the tests pass.

      I *think* this is the last inconsistency in the model. I hope.

    14. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    No one assigned

      Labels

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions