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

Don't hardcode endianness #283

Closed
lkatalin opened this issue Dec 10, 2021 · 1 comment
Closed

Don't hardcode endianness #283

lkatalin opened this issue Dec 10, 2021 · 1 comment

Comments

@lkatalin
Copy link
Contributor

Use the host endianness instead of to_le_bytes() or to_be_bytes(). I think there is an easy way to do this from byteorder but I'd have to look again.

sarroutbi added a commit to sarroutbi/rust-keylime that referenced this issue Aug 11, 2023
sarroutbi added a commit to sarroutbi/rust-keylime that referenced this issue Aug 11, 2023
Resolves: keylime#283

Signed-off-by: Sergio Arroutbi <[email protected]>
sarroutbi added a commit to sarroutbi/rust-keylime that referenced this issue Aug 11, 2023
Resolves: keylime#283

Signed-off-by: Sergio Arroutbi <[email protected]>
sarroutbi added a commit to sarroutbi/rust-keylime that referenced this issue Aug 11, 2023
@ansasaki
Copy link
Contributor

ansasaki commented Sep 7, 2023

Check if this is actually valid: the encoding is kept the same independently of the arch to avoid encoding errors due to endianess. A good approach to check is to test the changes proposed in #637 mixing big endian and little endian arches

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