validate digest lengths

[flokli]

Currently this crate does not validate the SSRI hashes to actually encode a digest that matches the size of the hash function used.

This means, the following SSRI succeds to parse:

sha256-pc6cFV7Qk5dhRkbJcX/HzZSxAj17drYY1Ank

… even though this only encodes 27 bytes, not 32:

❯ echo -n pc6cFV7Qk5dhRkbJcX/HzZSxAj17drYY1Ank | base64 -d | hexdump -C
00000000  a5 ce 9c 15 5e d0 93 97  61 46 46 c9 71 7f c7 cd  |....^...aFF.q...|
00000010  94 b1 02 3d 7b 76 b6 18  d4 09 e4                 |...={v.....|
0000001b

I'd expect this to fail.

[zkat]

I guess in the use cases I was using this for, there wasn't any knock-on effect of this happening. If they were longer or shorter didn't really affect the security of the result (as far as any way I could tell), but I can see how having this guarantee would bring peace of mind. Do you have a specific use case where this would cause problems for you? I guess if you're expecting general validation of these as-is...

[flokli]

I guess what makes this complicated is that you probably end up having to decode the base64 string, pulling in some more crates to do this properly.

I'm fine to do the base64 decoding and comparison against expected digest sizes outside, but I guess then it should be documented this crate doesn't do any further sanitization of the encoded digest.

[flokli]

I opened #6 to add this remark to the docs.

I also saw you already do pull in the base64 crate - in that case, it could probably be done easily.

I won't implement that though, as I ended up not being able to use this crate - the SRI hashes I needed to decode can also be md5 unfortunately (which is not supported by this crate), and don't support multiple hashes per string (which is unfortunate) - in the end it was easier to just write my own small decoder.

[zkat]

yeah it's not a super complicated thing to roll up yourself, for the most part. :)