crypto: implement privateEncrypt/publicDecrypt #625
Conversation
indutny
added
the
semver-minor
|
cc @bnoordhuis |
| @@ -3603,6 +3603,12 @@ bool PublicKeyCipher::Cipher(const char* key_pem, | |||
| if (EVP_PKEY_CTX_set_rsa_padding(ctx, padding) <= 0) | |||
| goto exit; | |||
|
|
|||
| /* Reset md for signatures, we are doing raw RSA ops anyway */ | |||
| if (EVP_PKEY_CTX_get_operation(ctx) == EVP_PKEY_OP_SIGN) { | |||
| if (EVP_PKEY_CTX_set_signature_md(ctx, nullptr) <= 0) | |||
There was a problem hiding this comment.
I admit I don't understand why it's necessary to clear the signature hash function. Can you explain? Preferably with a longer, in-code comment? :-)
There was a problem hiding this comment.
Oops forgot to remove it, it is no longer needed. :) This piece was failing because PSS padding mode set sha1 md and rsa_pmeth.c was ensuring that the input length matches the md output length. However, PSS does not really work with all these shit, so I replaced it with PKCS1, and PKCS1 does not set md.
|
LGTM if the CI is happy. |
|
Landed in 43c127c, thank you! |
|
Arrgh, in 87e62bd |
|
@bnoordhuis this is a new feature, I wonder if we should do v1.1.x with it? cc @rvagg |
|
Yes, we have a bunch of stuff queued up with semver-minor and it'd be great to land a bunch of them. Got a proposal for how we handle that? Do we just merge them in to v1.x and jump straight to 1.1.0 or do we make a branch so we can test stuff out first? I think that we're inevitably going to have at least some batching of semver-minor merges into the future so having a solid process in place for doing that would be nice. |
|
Since minor version changes shouldn't be breaking, we should be able to merge and bump the version. If we wanted to test it out first, would it be much effort to branch and release as nightlies? |
|
ok then! 1.1.0 it is, we'd best revisit all those semver-minor patches and see what can/should be merged. @cjihrig the situation I wouldn't mind avoiding is that we have so many feature additions staggered that we're always bumping minor, hence the desire for a bit of batching so we have a chance to get patch releases out and the list of features doesn't feel so unstable to users. This is just my personal opinion of course and I know others feel differently. And, yes it's easy enough to do nightlies, perhaps the best process for now is to allow at least a couple of days after merging semver-minor additions before cutting a release, to allow people to test things in nightlies. |
|
@rvagg I agree that we should batch minor bumps. I guess at least two questions would be 1) how long we should wait between minor bumps, and 2) how long to leave them in nightlies (is a week too long considering we've had multiple releases in less than that before). Maybe something for tomorrow's TC meeting? |
Fix #477