[
https://issues.apache.org/jira/browse/QPID-8402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17027474#comment-17027474
]
Alex Rudyy commented on QPID-8402:
----------------------------------
Hi Robbie,
Thanks for your input on the subject. The issue with pre-generated data is that
they do not feet all the use cases. As a new use case arises, either the new
generated item needs to be added or existing one updated. With a small number
of resources that might not be an issue. My current problem with pre-generated
resources is that there are too many of them, and, it is not clear in what
tests the resources are actually used without spending some time looking
through the code. More over, the existing tests seems are more influenced by
the pre-generated resources, rather than being implemented based on the actual
needs of the test case. The current test refactoring (work in progress) made me
to believe, that the tests became much more clear and easy to follow with
generation of resources on the fly. The attached patches might not make that
obvious, as they are far form the end state.
As for your argument, that if would be easier to debug the test problem with
pre-generated resource, I completely agree with it. Though, it should not be
that difficult to save the generated resource for later investigation.
The generation can also slow down the tests, but, I think it can be worked
around by keeping caches of resources for following reuse, if required. At the
moment, it is out of the scope of my re-factoring.
My current refactoring is based on the following ideas
* create utility class to generate TLS resources like keys, certificates, CRLs
etc
* create utility class responsible for the storing TLS resources in required
formats, like java keystores, pem and der files, etc
* create JUnit4 ExternalResource in order to inject {{@ClassRule}} responsible
for creation of the required resources to the test an automatic clean up of the
created resources after tests are complete. The following code illustrates the
idea:
{code}
public class MyTest extends UnitTestBase
{
@ClassRule
public static final TlsResource TLS_RESOURCE = new TlsResource();
@Test
public void testSomething() throws Exception
{
final File keyStoreFile = TLS_RESOURCE.createSelfSignedKeyStore(DN_FOO);
final Map<String, Object> attributes = new HashMap<>();
attributes.put(FileKeyStore.NAME, NAME);
attributes.put(FileKeyStore.STORE_URL, keyStoreFile.getAbsolutePath());
attributes.put(FileKeyStore.PASSWORD, TLS_RESOURCE.getSecret());
attributes.put(FileKeyStore.KEY_STORE_TYPE,
TLS_RESOURCE.getKeyStoreType());
final FileKeyStore<?> fileKeyStore = createTestFileKeyStore(attributes);
// ... test operations
// .... test asserts
}
@Test
public void testSomethingMoreComplecated() throws Exception
{
final KeyCertPair caPair =
TlsResourceGenerator.createKeyPairAndRootCA("CN=MyRootCA,O=ACME,ST=Ontario,C=CA");
final KeyPair clientKeyPair = TlsResourceGenerator.createRSAKeyPair();
final X509Certificate clientCertificate =
TlsResourceGenerator.createCertificateForClientAuthorization(clientKeyPair,
caPair, "[email protected],OU=art,O=acme,L=Toronto,ST=ON,C=CA", validityPeriod);
final KeyPair serverKeyPair = TlsResourceGenerator.generateRSAKeyPair();
final X509Certificate serverCertificate =
TlsResourceGenerator.generateCertificateForClientAuthorization(serverKeyPair,
caPair, "[email protected],OU=art,O=acme,L=Toronto,ST=ON,C=CA", validityPeriod);
final File serverKeyStoreFile = TLS_RESOURCE.createKeyStore(new
PrivateKeyEntry("broker", serverKeyPair.getPrivateKey(), serverCertificate,
caPair.getCertificate() ))
final File clientKeyStoreFile = TLS_RESOURCE.createKeyStore(new
PrivateKeyEntry("client", clientKeyPair.getPrivateKey(), clientCertificate,
caPair.getCertificate() ));
// implement the test operations with serverKeyStoreFile and
clientKeyStoreFile
}
}
{code}
* I am expecting to use the same approach for the integration tests when TLS
connectivity is tested
* I am considering putting all the TLS resource generation functionality into
{{org.apache.qpid:qpid-test-utils}} and have it declared as test dependency in
all modules where TLS resources are required
I am expecting to complete the refactoring over next week-end. I can create a
pull request for the review. Though, the pull request could be huge due to the
amount of changes. I am doing a clean up of the impacted tests.
It seems that amount of code required to implement the generation of TLS
resources with bouncy castle API is not that big. It feels as if I am deleting
more code, than actually adding new one.
At the moment, I am pretty confident, that generation of TLS resources on the
fly would make existing tests better. The resource generation would make
creation of new tests easier.
> [Broker-J][Tests] Use Bouncy Castle API to generate certificate resources on
> the fly in unit and system tests
> -------------------------------------------------------------------------------------------------------------
>
> Key: QPID-8402
> URL: https://issues.apache.org/jira/browse/QPID-8402
> Project: Qpid
> Issue Type: Task
> Components: Broker-J
> Reporter: Alex Rudyy
> Priority: Major
> Fix For: qpid-java-broker-8.0.0
>
> Attachments:
> 0001-QPID-8402-Broker-J-Add-bouncycastle-test-dependecies.patch,
> 0002-QPID-8402-Broker-J-Add-generation-of-self-signed-cer.patch
>
>
> Qpid Broker-J unit tests rely on a number of pre-generated kesstores,
> truststores, certificates, etc located either in module test resources folder
> or/and project folder {{./test-profiles/test_resources/ssl}}. Those
> resources need to be regenerated periodically in order to keep them valid and
> up to date. As part of work at QPID-8367, the number of required test
> resources has increased.
> A bash script was created in order to automate the generation, though, it
> seems, that a better approach would be to generate the required resources on
> runtime using Bouncy Castle API.
> It is not exactly clear whether Bouncy Castle API would allow to generate
> all required test resources (including those added in QPID-8367). Though, we
> should switch to using Bouncy Castle API where it is possible, especially,
> for generation of self-signed certificates and test CA authority certificates
> and corresponding keystores/truststores.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
