Closed arsenalzp closed 8 months ago
Hi @arsenalzp. Thanks for your PR.
I'm waiting for a cert-manager member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test
on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.
Once the patch is verified, the new status will be reflected by the ok-to-test
label.
I understand the commands that are listed here.
Hello colleagues, Should I put an improvement in current PR? If so, could you be so kind put your remarks 🙂
Hello colleagues, Should I put an improvement in current PR? If so, could you be so kind put your remarks 🙂
Please rebase the PR and ensure you have run make generate
. I still see the password field marked as required in the generated OpenAPI schema, and that's not correct. And another tip, at least when I am the reviewer: please resolve conversations when they are fixed! If needed they can be reopened. It just makes the review process more comfortable for all parties.
Let me know if you need help rebasing. It is a skill you should master, but it always feels a bit uncomfortable the first couple of times.
All remarks were fixed, branch was re-based as well.
/ok-to-test
Nice, thanks for this. Almost LGTM from me. Are we able to add some tests using this new feature? It seems like all tests use the default passwords.
Hello, Yes, I will add tests for both stores, which use arbitrary password. Is that correct?
I spent the whole evening with troubleshooting PKCS12 test case, and I've just found that PKCS12 encoders are not deterministic:
$ openssl pkcs12 -nokeys -in test.pem -export -out test.p12 -password pass:qwerty
$ md5sum test.p12
9176d1b36d911766e74810ff0fa3bbcd test.p12
$ openssl pkcs12 -nokeys -in test.pem -export -out test.p12 -password pass:qwerty
$ md5sum test.p12
89b666d7907c0b8420470f1c25a66c2b test.p12
I spent the whole evening with troubleshooting PKCS12 test case, and I've just found that PKCS12 encoders are not deterministic:
Yes, both JKS and PKCS12 adds some salt making them non-deterministic. I think the tests must be created with that in mind. What's wrong with the existing test approach?
I spent the whole evening with troubleshooting PKCS12 test case, and I've just found that PKCS12 encoders are not deterministic:
Yes, both JKS and PKCS12 adds some salt making them non-deterministic. I think the tests must be created with that in mind. What's wrong with the existing test approach?
Thank you for a hint! I was trying to put test in bundle_test.go. Now it works!
/retest
@arsenalzp Maybe you can update the PR title and description? It seems like I am not allowed to do it. I suggest;
@arsenalzp Maybe you can update the PR title and description? It seems like I am not allowed to do it. I suggest;
* rewording the title to describe the feature added * change "relates to" to "fixes" [Support of setting arbitrary password for PKCS12 truststore #199](https://github.com/cert-manager/trust-manager/issues/199) (so the issue will be closed on merge of this PR)
Done!
/retest
A couple of suggestions to API docs improvements, but
/lgtm
Fixes were implemented.
/retest
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: erikgb, inteon
The full list of commands accepted by this bot can be found here.
The pull request process is described here
/unhold
This PR fixes #199 . As was proposed by @erikgb, two dedicated structures PKCS12 and JKS were added. Could you please be so kind to review this PR?