Ingela/ssl/custom sign fun #7898
Conversation
CT Test Results 3 files 71 suites 49m 6s ⏱️ Results for commit ac3a3b0. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
|
true, we can use M:F/2 to set the function in |
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
3 times, most recently
from
a2c6e52
to
39e88d8
Compare
IngelaAndin
added
the
testing
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
from
d5991d8
to
a0b9734
Compare
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
3 times, most recently
from
750ee1f
to
2ff6ac4
Compare
|
@ziopio I think we will also want to be able to give custom options to the fun, to for instance be able to provide some kind or reference to the key to enable the fun to find/access it. In the test you wrote this is not necessary as the key is directly accessible in as it only wraps the standard keys. |
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
from
2ff6ac4
to
c4e2704
Compare
|
@IngelaAndin Yeah we do not have an use-case since in our scenario we control both the code that uses SSL and the signfun and a developer can just embed his/her options inside the function implementation. That said such option can help writing a general purpose custom function. So yeah, I think is a good Idea 👍 |
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
from
c4e2704
to
873a36c
Compare
|
Waiting for @dgud review |
|
Also a lot of white-space changes in ssl.erl that is touching (not emacs?) non updated code which will cause a lot of merge-conflicts later. |
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
from
873a36c
to
c28f1cc
Compare
|
@dgud please rereview doc |
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
from
c28f1cc
to
7347e58
Compare
This option allows the user to define a function tasked to sign an ssl message. This gives total freedom around key handling. Users are free to program such function the way they think is best, allowing them to support any private key storage or to delegate signature to any external service or device. Most notably: this allows to implement custom access to any HSM device.
Do not use undocumented OpenSSL "implicit param", rather be explicit about what PSS params that where negotiated.
IngelaAndin
force-pushed
the
ingela/ssl/custom_sign_fun
branch
from
7347e58
to
ac3a3b0
Compare
|
@dgud rereview doc and added tests |
Last commit show what we like the API to look like in #7475 (Commits now squashed and this PR replaces #7475)
Design decisions:
Keep all engine stuff in ssl, although it is a corner case of the more general
customization added, it has nothing to do with the functionality in public_key.
Keep options sign/encrypt_private options explicit in ssl, where the knowledge of correct options belong, do not rely on public_key defaults that are not even documented.
There has to be a legacy fun option for TLS legacy versions using encrypt_private as new version and legacy version can be supported in the same time and is negotiated.
We do not want to support funs on format {Module, Fun}. fun() is sufficient and you can
use
fun(X,Y) ...or fun M:F/2