rhash does not handle special characters.

[bac0n]

rhash will break checking on special characters in linux.

$ touch 'd'$'\n''e'  'd'$'\r''e'

[rhash]

Thanks for reporitng the problem. The bug is reconfirmed.

RHash fails to verify 'd'$'\n''e', although successfully verifies 'd'$'\r''e' on Linux. Also filenames in verification results and errors are displayed unescaped:

$ rhash -M 'd'$'\n''e' | rhash -Mc -

--( Verifying (stdin) )---------------------------------------------------------
d                                                   No such file or directory
RHash: can't parse line: e
--------------------------------------------------------------------------------
Errors Occurred: Errors:0   Miss:1   Success:0   Total:1

$ rhash -M 'd'$'\r''e' | rhash -Mc -

--( Verifying (stdin) )---------------------------------------------------------
e                                                 OK
--------------------------------------------------------------------------------
Everything OK

While GNU utilities work:

$ for s in b2sum md5sum sha1sum sha256sum sha512sum; do echo $s; $s d*e > hash; $s -c hash; done
b2sum
\d\ne: OK
e: OK
md5sum
\d\ne: OK
e: OK
sha1sum
\d\ne: OK
e: OK
sha256sum
\d\ne: OK
e: OK
sha512sum
\d\ne: OK
e: OK

There exists a related problem with filenames containing backslash, since when RHash finds a backslash in a hash file it decides that hash file is generated on Windows and treats backslash as a path separator.

Some supported by RHash hash formats allow to deal with this, since Windows paths forbid special characters (backslash and characters with codes from 0 to 31). So an escaped line can be generated only on Linux and backslash shall be treated as a path separator only in unescaped lines.

Magnet and Ed2k links contains urlencoded filename and there is no way to differ Windows and Linux backslashes. At last BSD format also should be checked if it can handle special characters.

Due to the problem complexity, the fix should not be expected in the nearest time.

[rhash]

Regading supported by RHash BSD format. FreeBSD UFS allows any characters in filenames except NUL.

Original BSD utilities sha1, sha256, sha512 (tested on OpenBSD) are broken for character '\n':

$ touch "$(printf 'a\re')" "$(printf 'a\ne')"
$ sha512 a*e >hash.sha512
$ sha1 a*e >hash.sha1
$ sha1 -c hash.sha1
sha1: cannot open = da39a3ee5e6b4b0d3255bfef95601890afd80709: No such file or directory
(SHA1) = da39a3ee5e6b4b0d3255bfef95601890afd80709: MISSING
e: OK) a
$ sha512 -c hash.sha512
sha512: cannot open = cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e: No such file or directory
(SHA512) = cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e: MISSING
e: OK12) a

As expected, filenames are also not escaped when errors are reported.

But GNU utilities md5sum, sha1sum, ... support BSD format with special characters escaping extension:

‘--tag’ Output BSD style checksums, which indicate the checksum algorithm used. As a GNU extension, if --zero is not used, file names with problematic characters are escaped as described above, with the same escaping indicator of ‘\’ at the start of the line, being used.

[rhash]

Changing issue to 'Feature Request', since this case is complicated and is nether correctly handled by *BSD native hashing utilities.

[rhash]

The feature is supported by commits: 5ab59ef592826f91b59484a86072cc35b2e8d699, 357e7d37961f589278159cc9bff6fe9369cf4db7.

[rhash]

Implemented in RHash v1.4.4.