SQLx, Diesel, etc RUSTSEC tracking issue.

[the10thWiz]

SQLx and Diesel have opened a RUSTSEC advisory for a bug in the binary transmission protocol. There is nothing we can directly do to help, beyond bumping our dependency versions once they have been merged.

• SQLx: Potential vulnerability: overflowing and truncating casts launchbadge/sqlx#3440
• Diesel: Enable some numeric cast releated clippy lints and fix them in the code base diesel-rs/diesel#4170

During this process, I tried out the RUSTSEC auditing tool, and it looks like we also have two other potential issues, although as in this case, there is nothing we can do for now.

[SergioBenitez]

Rocket limits all user input by default. As such, there's no way to exhibit this issue without either passing very large input you create yourself, the negative effects of which you'd see directly, or using custom and exuberantly large >= 4GiB limits for input that flows into one of the affected sinks, which is extremely unlikely in general. Nevertheless, Rocket is doing something about this already, and as a general mechanism, it's all we can do. As such, I don't believe there's anything for us to track here as Rocket users are unaffected by default and extremely unlikely to be affected altogether.

[the10thWiz]

I guess that's a fair assessment. Although I had seen that detail, I didn't make the connection to data limits. Raising the data limit to larger than 4GiB is likely enough to eliminate it as a DoS protection, so I think we can consider this a non-issue.

That being said, I think it's possible for a Rocket application to trigger this without changing the input limits (although it's extremely unlikely). I may have jumped the gun a bit, just because I saw that they went as far as opening a RUSTSEC advisory.