Mark Key::from_bytes as safe

[Veykril]

It doesn't seem to make sense to me as to why this is unsafe, when you have a safe constructor that takes an arbitrary string whose Key you could still use incorrectly. But also more importantly, Key implements Deserialize which means it is already possible to create abitrary keys via deserialization with arbitrary inputs.

So either this constructor ought to be safe, or Key::for_path needs to be also unsafe and the Deserialize impl has to be removed.

[netlify]

✅ Deploy Preview for cute-starship-2d9c9b canceled.

Name	Link
🔨 Latest commit	a1b66ae
🔍 Latest deploy log	https://app.netlify.com/projects/cute-starship-2d9c9b/deploys/685431c4b30e31000847cd73

[jamesmunns]

Yeah, it being unsafe is probably a little strong. In general, I should make it more clear that Key should NEVER be used to guarantee type-safety, only as a hint to what type the frame may contain. Deserialization is still checked with serde, so you will never hit memory safety issues, but you could still get relatively "garbage" values out of the deser of the "wrong" type, same as any malicious packet.

I also should do a better job in postcard-rpc of enforcing that deser consumes all bytes, which will also help with "successfully deser'd the wrong type" issues.

[Veykril]

Fwiw the mention of deserialize is because implementing Deserialize on a type effectively adds a new safe public constructor to the type. Whether your Deserialize impl is well behaved is not relevant for my argument.

[jamesmunns]

Yep, got it! Definitely aware of that.

[jamesmunns]

Thank you!