ZKVM-1458: Update RSA patch to v0.9.9 #8
Conversation
Otherwise the inner precompute could fail
Currently, this crate allows instantiation of public keys larger than 4096 bit (via `RsaPublicKey::new_with_max_size`), but doing cryptographic operations with such public keys fails in `key::check_public`, which always checks the modulus size against the constant `RsaPublicKey::MAX_SIZE`. I think it would be nice to cap both public and private key sizes to 4096 bit by default, but to allow opt-in creation of larger keys (complete with working cryptographic operations).
github-actions
bot
changed the title
|
Note that most of the diff comes from the merged commits. Clicking on the individual commits will show what I changed. |
|
This seems ok, but I wonder if we should avoid merging tags. To me each branch that relates to the upstream branch should have one or more risc0 commits relating to the changes needed. It might be safe this time, but in general we should probably try and commit the set of commits for risc0 ontop of whatever tag we are patching, rather than trying to move this branch forward a tag at a time. |
|
I'm not sure it makes sense to have a single |
|
Can you clarify the suggested workflow. Are you suggesting that I rebase the RISC Zero commits (i.e. those made by our team) on top of the patch that I intend to patch? Or maybe you are thinking something else? As for branches, yes I think it makes sense to have separate branches. In this repo (RSA) in particular, the line from |
This PR merges in the upstream commits up to v0.9.9. It additionally updates to use the latest version of
risc0-bigint2, fromcrates.ioinstead of a git dependency, and does some work to allow forcargo risczero guest testto work in this repo.This PR should be merged into
risc0as a rebase, preserving this constituent commits instead of squashing them. Once this is done, tags forv0.9.8-risczero.0andv0.9.9-risczero.0can be pushed as new releases of this patch.