Patch for [ 1170331 ] Error in base64.b32decode

[logistix]

BPO	1171487
Nosy	@akuchling
Files	base32decode_fix.diff

^{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 = 'https://github.com/akuchling'
closed_at = <Date 2005-06-08.22:53:58.000>
created_at = <Date 2005-03-27.19:46:17.000>
labels = ['library']
title = 'Patch for [ 1170331 ] Error in base64.b32decode'
updated_at = <Date 2005-06-08.22:53:58.000>
user = 'https://bugs.python.org/logistix'

bugs.python.org fields:

activity = <Date 2005-06-08.22:53:58.000>
actor = 'akuchling'
assignee = 'akuchling'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2005-03-27.19:46:17.000>
creator = 'logistix'
dependencies = []
files = ['6573']
hgrepos = []
issue_num = 1171487
keywords = ['patch']
message_count = 3.0
messages = ['48062', '48063', '48064']
nosy_count = 2.0
nosy_names = ['akuchling', 'logistix']
pr_nums = []
priority = 'high'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1171487'
versions = ['Python 2.4']

[logistix]

base64.b32decode didn't decode some things properly.
Seems to have only impacted characters with a value <
32. Attached is a fix and a new test.

[logistix]

Logged In: YES
user_id=699438

Updated patch to reflect another fix.

I originally thought the bug was related to cleanup of a
partial quanta. It will trigger on any quanta where the
initial hex value is < 0x10. When this happens part of the
hex code disappears in the initial conversion and is
mistakenly swallowed. The hex function that was originally
used doesn't zero-pad, but the way the bit shifting works,
it doesn't need to when encoding normal alpha-numeric
characters, so it seemed to work correctly.

This will only cause problems if you are using a character
value of < 0x10 in the 0th, 4th, 8th, 12th, etc positions in
the encoded string. Otherwise it'll work properly. Using
"%010x" ensures that you'll get the appropriate zero-padding
if necessary.

Example of more broken code not covered in the original bug:

>>> base64.b32decode(base64.b32encode('\x00aaa'))
'aaa'

Updated patch fixes this case as well.

[akuchling]

Logged In: YES
user_id=11375

Applied; thanks! I also added a test case that would have
caught the bug.