Skip to content
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

branca decode does not handle binary data #10

Closed
rhizoome opened this issue Nov 5, 2020 · 3 comments · Fixed by #11
Closed

branca decode does not handle binary data #10

rhizoome opened this issue Nov 5, 2020 · 3 comments · Fixed by #11

Comments

@rhizoome
Copy link

rhizoome commented Nov 5, 2020

  1. Take another branca implementation (eg. pybranca)
  2. Encode binary data
f = Branca(fromstring(key))
ct = f.encode(b"\x80")
  1. Pass ct do decode in this implementation

-> it will return b'\xef\xbf\xbd'

The spec allows binary data:

..... serialized by MessagePack or Protocol Buffers. from branca.io

@brycx
Copy link
Collaborator

brycx commented Nov 5, 2020

This seems to be due to the expectation that the encoded data is valid UTF-8:

Ok(String::from_utf8_lossy(&buf_crypt).into())

This is compatible with this implementation's encode function, which takes &str. But if another implementation is used to encode non-valid UTF-8, then the above happens (playground).

decode() could return Vec<u8> instead of String to solve this.

In terms of spec-compliance, then encode should probably also take raw bytes instead of &str:

"Payload itself is an arbitrary sequence of bytes."

@J-F-Liu
Copy link

J-F-Liu commented Nov 16, 2020

@brycx Suggest use AsRef<[u8]> in encode function.

pub fn encode<T: AsRef<[u8]>>(data: T, key: &[u8], timestamp: u32) -> Result<String, BrancaError>

@brycx
Copy link
Collaborator

brycx commented Nov 29, 2020

@J-F-Liu Thank you for the suggestion. I think your proposal could be a good idea. However, @return currently is very busy and has given me permission to merge and update the crate with the purpose of fixing current bugs. As there were no generic parameters used in function signatures before, I will not add these now. This is simply to change as little as possible in order to fix the issue and stick to the current API as much as possible. I will open an issue for generic parameters, which @return can then decide upon once they have time again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants