Open hacklschorsch opened 3 years ago
I think any other users of python-challenge-bypass-ristretto still have the same problem so this should remain open.
Thanks! Which ones do? We should file bugs there then I guess.
The decision to export such a German API is valid, I guess, even if a bit more laissez faire would be nice of course. I don't see it as a bug really.
What kind of fix would you like to see?
I'd be happy with either of the expected behaviors suggested in the issue description (maybe with a custom exception type instead of a lot of words for the exception case).
I am setting up a tahoe-LAFS storage node, and ran into a problem where the key could not be decoded:
If the file holding the ristretto key ends with a newline, or a blank, or something not a NUL byte apparently, the decoding will fail with a pretty opaque
DecodeException()
without further info. This has cost me a couple of hours :( In the past I only had systems fail because files didn't end with a newline, so this is a fun and welcome change. Even better I would like more robust parsing.Or maybe just add this to the spec and make our users call
.strip()
on the strings they senddecode_base64()
's way?Steps to reproduce
Note the blank character at the end of the string.
Expected behaviour
Maybe just work:
Or maybe fail with a more specific error description:
Actual behavior
Workaround
Write your key file with
echo -n
or a proper editor that lets you not add a newline. (I had only nano on that system, not great.)