In the SNIA documents it is clearly stated that only specific ltfs.hash.<hashtype>:s xattrs and formats are conforming:
| hashtype |
algorithm |
bits |
hex chars |
| crc32sum |
ANSI X3.66 |
32 |
8 |
| md5sum |
RFC 1321 |
128 |
32 |
| sha1sum |
FIPS 180-4 |
160 |
40 |
| sha256sum |
FIPS 180-4 |
256 |
64 |
| sha512sum |
FIPS 180-4 |
512 |
128 |
Currently this implementation allows for writing any values and with any names into the ltfs.hash.<hashtype> xattrs.
To Reproduce
Steps to reproduce the behavior on linux builds (all examples here use non conforming attribute names):
setfattr -n user.ltfs.hash.sha256 -v "tooshort" file # text, wrong length (spec wants 64 hex chars)
setfattr -n user.ltfs.hash.crc32 -v 0xdeadbeef file # 0x… = raw BINARY bytes (spec wants UTF-8 hex text)
setfattr -n user.ltfs.hash.md5 -v 0sBgYGBgYG…== file # 0s… = raw bytes from base64
Expected behavior
LTFS should prevent from writing non-conformant information in the xatrrs.
Any thoughts on this?
In the SNIA documents it is clearly stated that only specific
ltfs.hash.<hashtype>:s xattrs and formats are conforming:Currently this implementation allows for writing any values and with any names into the
ltfs.hash.<hashtype>xattrs.To Reproduce
Steps to reproduce the behavior on linux builds (all examples here use non conforming attribute names):
Expected behavior
LTFS should prevent from writing non-conformant information in the xatrrs.
Any thoughts on this?