Tony Arcieri

@fjarri we have the `*Monty*` types to optimize previously reduced operands. The solution to this bug shouldn’t impact performance too much. We just need to wrap the initial subtraction at...

Still feels like a huge footgun to me. If you want to avoid the additional computation, what’s the problem with using the `*Monty*` types to ensure the inputs are properly...

@lleoha that's a good point. I guess I'd be okay with a fast `sub_mod_unchecked` that documents its caveats, but IMO `sub_mod` should *never* miscompute results.

@nemynm can you rebase?

We generally don't expose user choices which allow users to shoot themselves in the foot via misuse. The traits all map to different signature algorithm APIs and the different parameters...

P-256 isn't a signature algorithm. ECDSA / P-256 is a signature algorithm. However, our implementation of ECDSA is generic. The trait impls are all in that crate: - https://docs.rs/ecdsa/latest/ecdsa/struct.SigningKey.html -...

Given `cargo-audit`'s role as a Cargo.lock analyzer, there's little we can do without implementing a much more complicated analysis which can incorporate Cargo.toml as well, which has been discussed in...

`cargo-tree` isn't exactly designed for programmatic consumption, and it's a heavy dependency. To properly consume data from Cargo.toml files / Rust workspaces it would be better if we optionally linked...

Yeah, this is definitely a worthwhile issue to track, whether the solution happens upstream in Cargo or via new features added to `cargo-audit`.

The cargo issue I linked earlier suggests this issue occurs with `cargo metadata` as well