-
Notifications
You must be signed in to change notification settings - Fork 187
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
EncodeOctets fails when bytes() starts with b'0x' #152
Comments
@nward @Istvan91 I appreciate the patch, but I think that this still has problems, consider these two cases:
I'm also not sure how to fix it without breaking semantics. In my code I've worked around the issue by always hex encoding strings and bytes before giving them to the library. |
What problem do you see with the semantics? The "obvious" solution would be to just catch the binascii error and fall back to treating the parameter as a "normal" str/bytes. |
The problem I originally ran into was that my Catching the exception would prevent that from happing, and would instead fail to treat For the MD5, there are 16 bytes of hash, and this will happen when the first digit is My workaround was to always hex-encode it, regardless of the content, so it would always hit the hex decoding branch. |
I just ran into this, and as @jokjr said, the bugfix itself is a bug. We are forced to always hex encode it (using an old version right now, so even doing A byte string can by definition contain any characters. It can include The ugly thing is, you cannot fix this without breaking some code out there, in particular because I guess you do not have any choice but either breaking the API or adding a new sane API. Maybe one that just completely bypasses the encoding API and asserts that a byte string is passed. No one in their right mind would pass a bytestring that contains hex encoded binary. And if one has a bytestring, then doing the |
EncodeOctets
fails when abytes
object starts with0x
- I ran into this where my code was failing after 50.000 invocations because I was assigning random bytes to an octet attribute(253 - len('0x')) / 2 == 125.5
. I looks like it should do the length checking after the decoding?EncodeString
also runs before the encoding, so if encodingsix.text_type
can expand during encoding that might also be work looking into. I don't know whatsix.text_type
is, so I can't say if this is an issue.I think the fix would be to have something like:
See:
pyrad/pyrad/tools.py
Lines 14 to 26 in 59b8a15
The text was updated successfully, but these errors were encountered: