Skip to content

feature: support load private key with password #973

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 9 commits into from

Conversation

detailyang
Copy link
Contributor

I hereby granted the copyright of the changes in this pull request
to the authors of this lua-nginx-module project.

@agentzh This feature is separated at #957 . Now It adds the FFI API as the following:

int
ngx_http_lua_ffi_priv_key_pem_to_der_with_password(const u_char *pem,
    size_t pem_len, const u_char *pwd, size_t pwd_len, u_char *der, char **err);

void *
ngx_http_lua_ffi_parse_pem_priv_key_with_password(const u_char *pem,
    size_t pem_len, const u_char *pwd, size_t pwd_len, char **err);

When we think it can be merged to master, I will create another PR for lua-resty-core to implment load private with password.

{
BIO *in;
EVP_PKEY *pkey;
ngx_str_t password;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Coding style issue. Please use the ngx-releng script to check your code. Thank you.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stupid error:(.




=== TEST 6: simple cert + private key with password
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better create a new .t file to avoid growing this test file from forever :)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, we can simply test the Lua API here instead of the plain C API since lua-resty-core is already visible to this module's test suite.

Finally, I think you can use the new add_block_preprocessor feature of Test::Nginx::Socket to avoid the massive code duplication in these SSL related tests. See

http://search.cpan.org/dist/Test-Nginx/lib/Test/Nginx/Socket.pm#add_block_preprocessor

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FWIW, the pattern i've been using is testing the C FFI function in lua-nginx-module and test the Lua function in lua-resty-core. Otheriwse you create a co-dependency on both repos that makes the tests fail for both lua-nginx-module and lua-resty-core PRs until you merge both. (Assuming this is what you meant in the first paragraph).

Copy link
Contributor Author

@detailyang detailyang Feb 3, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@agentzh Thanks for you suggestion, I will take a look at add_block_preprocessor.

@ghedo what's your meaning? My plan is to add the new api at first. When we let it merge to master then creating another PR to lua-resty-core. Is that wrong?

Now I know what's yours meaning, So we just simply test the C API in lua-nginx-module and test the Lua API in lua-resty-core :D

int len;
BIO *in;
EVP_PKEY *pkey;
ngx_str_t password;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

idem (missing space)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

stupid error:(.

@@ -34,4 +34,35 @@ ngx_http_lua_ssl_init(ngx_log_t *log)
}


int
ngx_http_lua_ssl_password_callback(char *buf, int size, int rwflag,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should probably be moved to ngx_http_lua_ssl_certby.c and declared static since it's only used there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe ngx_http_lua_ssl_password_callback is a useful function ? I mean that it will be used in other scene like cosocket in future.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@detailyang I personally prefer @ghedo 's suggestion.
When it will be used in other place, we can move it out in the future :)

@detailyang
Copy link
Contributor Author

@agentzh @ghedo @thibaultcha

Will you please look at the new codebase, Many thanks :D

@@ -34,4 +34,35 @@ ngx_http_lua_ssl_init(ngx_log_t *log)
}


int
ngx_http_lua_ssl_password_callback(char *buf, int size, int rwflag,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@detailyang I personally prefer @ghedo 's suggestion.
When it will be used in other place, we can move it out in the future :)

@@ -982,6 +982,51 @@ ngx_http_lua_ffi_priv_key_pem_to_der(const u_char *pem, size_t pem_len,
}


int
ngx_http_lua_ffi_priv_key_pem_to_der_with_password(const u_char *pem,
size_t pem_len, const u_char *pwd, size_t pwd_len, u_char *der, char **err)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about reuse the current ngx_http_lua_ffi_priv_key_pem and pwd == NULL means without password?
So that we can reuse most of the code.

Copy link
Contributor Author

@detailyang detailyang Feb 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@doujiang24 I have considered the ngx_http_lua_ffi_priv_key_pem. But there are some existing tests which are rely on it. I'm not sure it's worth to change the ngx_http_lua_ffi_priv_key_pem. So just add the new api ngx_http_lua_ffi_priv_key_pem_to_der_with_password, then reimplement the Lua FFI API ngx.ssl.priv_key_pem_to_der to support password

So if we almost agree to reimplement the ngx_http_lua_ffi_priv_key_pem, I will try to do :D

@@ -0,0 +1,584 @@
# vim:set ft= ts=4 sw=4 et fdm=marker:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's fine to use t/151-ssl-c-api-password.t, so that we don't need to rename t/141-luajit.t to t/151-luajit.t.
The num order is not important here:)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gotcha

@detailyang
Copy link
Contributor Author

@doujiang24 @ghedo @agentzh

Now the only question is that we can choose to reimplement ngx_http_lua_ffi_priv_key_pem_to_der and ngx_http_lua_ffi_parse_pem_priv_key to adding the password param but may introduce the risk because of doing more change for some tests and lua-resty-core or adding the new API ngx_http_lua_ffi_priv_key_pem_to_der_with_password and ngx_http_lua_ffi_parse_pem_priv_key_with_password

What's your guys suggestion?

@guanglinlv
Copy link
Contributor

guanglinlv commented Mar 3, 2017

@detailyang , see #750 if you want to reuse ngx_http_lua_ffi_priv_key_pem_to_der.

@agentzh
Copy link
Member

agentzh commented Mar 3, 2017

@detailyang Huh, that is another reason why we shouldn't call into C functions directly through FFI in lua-nginx-module's test suite. We should really only test the lua-resty-core Lua API instead ;)

@detailyang
Copy link
Contributor Author

detailyang commented Mar 4, 2017

@agentzh Thanks.
Finally I do understand what's the meaning for 'simply test' when you are always teaching me 'simply test' in some code reviews :D

@zhuizhuhaomeng
Copy link
Contributor

zhuizhuhaomeng commented Jan 23, 2022

This PR implements the same function #1991
We have merged that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants