Cryptography is not far off of bc. It is deterministic and should be easily testable.
My bc is battle-hardened because I did my due diligence. The authors of the Cryptography library are writing _crypto_, which requires such due diligence. Did they?
What I should add to the post is that if they were not planning on doing that due diligence from the start, they should have written it in Rust from the beginning and not made promises to users that they couldn't keep.
It’s open source software. There are no promises.
However, if I was very careful with bc, despite the fact that no one was going to exploit it (which would not be the case if there was a vector for it, such as someone using bc in a script that runs as root), how much more careful should the Cryptography authors have been, since they were writing crypto?
And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users.
Edit: typo.
Did you consider that they are being careful by rewriting it in Rust?
> And if they were not going to be careful, they should have used Rust from the beginning and not made (implicit) promises to users.
Maybe Rust wasn't quite there at that point.
So they are only starting to be careful after several years? I addressed that point in the post.
> Maybe Rust wasn't quite there at that point.
It wasn't. But that's the point. Rust wasn't there, it's not there now. It needs to be as portable as C to be "there".
No since you’ll get to the “battle tested” point much fastener.
I'm not sure what you mean here.
Are you saying that a bc will get to a battle-tested state faster than crypto?
If you are, I disagree whole-heartedly. Crypto is bigint math with a few extras. bc has bigint math, a lexer, a parser, and an interpreter. Of those, the parser and interpreter are far more complicated than the bigint math.
And bc's bigint math is not actually just bigint; it's bigdecimal.