add dedicated structures for PKCS12 and JKS stores

[arsenalzp]

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?

[jetstack-bot]

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[erikgb]

@arsenalzp Please try to avoid closing PRs and opening new ones. It makes it harder to track work on this new feature.

I still think the API additions need a bit more work, and again I think this is the most important part. Making a field with a default required does not make sense to me. Though a password IS required, it has a default. So it is not required from the user's point of view. I've put up some suggestions, but I am not sure about the min/max length requirements. It is not easy to find any good specification of these legacy formats.

[arsenalzp]

Hello colleagues,
Should I put an improvement in current PR? If so, could you be so kind put your remarks 🙂

[erikgb]

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.

[erikgb]

Added a few suggestions. I wonder if we should not use the default passwords in tests. Ideally, the defaults should be just be present in the API spec.

[arsenalzp]

All remarks were fixed, branch was re-based as well.

[erikgb]

/ok-to-test

[erikgb]

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.

[arsenalzp]

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?

[arsenalzp]

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

[erikgb]

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?

trust-manager/pkg/bundle/sync_test.go

Lines 1541 to 1573 in 01bd331

	if test.expJKS {
	reader := bytes.NewReader(binData)
	ks := jks.New()
	err := ks.Load(reader, []byte(DefaultJKSPassword))
	assert.Nil(t, err)
	entryNames := ks.Aliases()
	assert.Len(t, entryNames, 1)
	assert.True(t, ks.IsTrustedCertificateEntry(entryNames[0]))
	// Safe to ignore errors here, we've tested that it's present and a TrustedCertificateEntry
	cert, _ := ks.GetTrustedCertificateEntry(entryNames[0])
	// Only one certificate block for this test, so we can safely ignore the `remaining` byte array
	p, _ := pem.Decode([]byte(data))
	assert.Equal(t, p.Bytes, cert.Certificate.Content)
	}
	binData, pkcs12Exists := resolvedBundle.binaryData[pkcs12Key]
	assert.Equal(t, test.expPKCS12, pkcs12Exists)
	if test.expPKCS12 {
	cas, err := pkcs12.DecodeTrustStore(binData, DefaultPKCS12Password)
	assert.Nil(t, err)
	assert.Len(t, cas, 1)
	// Only one certificate block for this test, so we can safely ignore the `remaining` byte array
	p, _ := pem.Decode([]byte(data))
	assert.Equal(t, p.Bytes, cas[0].Raw)
	}
	})

[arsenalzp]

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?

trust-manager/pkg/bundle/sync_test.go

Lines 1541 to 1573 in 01bd331

	if test.expJKS {
	reader := bytes.NewReader(binData)
	ks := jks.New()
	err := ks.Load(reader, []byte(DefaultJKSPassword))
	assert.Nil(t, err)
	entryNames := ks.Aliases()
	assert.Len(t, entryNames, 1)
	assert.True(t, ks.IsTrustedCertificateEntry(entryNames[0]))
	// Safe to ignore errors here, we've tested that it's present and a TrustedCertificateEntry
	cert, _ := ks.GetTrustedCertificateEntry(entryNames[0])
	// Only one certificate block for this test, so we can safely ignore the `remaining` byte array
	p, _ := pem.Decode([]byte(data))
	assert.Equal(t, p.Bytes, cert.Certificate.Content)
	}
	binData, pkcs12Exists := resolvedBundle.binaryData[pkcs12Key]
	assert.Equal(t, test.expPKCS12, pkcs12Exists)
	if test.expPKCS12 {
	cas, err := pkcs12.DecodeTrustStore(binData, DefaultPKCS12Password)
	assert.Nil(t, err)
	assert.Len(t, cas, 1)
	// Only one certificate block for this test, so we can safely ignore the `remaining` byte array
	p, _ := pem.Decode([]byte(data))
	assert.Equal(t, p.Bytes, cas[0].Raw)
	}
	})

Thank you for a hint!
I was trying to put test in bundle_test.go.
Now it works!

[arsenalzp]

/retest

[erikgb]

Thanks @arsenalzp! Did a quick review now. Just one suggestion. I would like to take a closer look and another review from a maintainer before we merge.

Fixes #199

/approve
/hold

[inteon]

LGTM, just one small typo

[erikgb]

@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 (so the issue will be closed on merge of this PR)

[arsenalzp]

@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!

[SgtCoDFish]

Only a few minor bits from me - thank you for working on this! ❤️

[arsenalzp]

/retest

[inteon]

/approve
/lgtm
/hold in case someone else wants to review

[erikgb]

A couple of suggestions to API docs improvements, but

/lgtm

[arsenalzp]

A couple of suggestions to API docs improvements, but

/lgtm

Fixes were implemented.

[arsenalzp]

/retest

[erikgb]

/lgtm

Thanks a lot for finishing this @arsenalzp!

[jetstack-bot]

[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

Needs approval from an approver in each of these files:

• OWNERS [erikgb,inteon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[inteon]

/unhold