On Fri, Jun 24, 2016 at 12:08:24PM +0200, Milan Kubík wrote: > On 06/24/2016 03:42 AM, Fraser Tweedale wrote: > > On Tue, Jun 21, 2016 at 05:01:35PM +0200, Milan Kubík wrote: > > > Hi Fraser and list, > > > > > > I have made changes to the test plan on the wiki  according to the > > > information in "[Testplan review] Sub CAs" thread. > > > > > > I also implemented the tests in the test plan: > > > > > > patch 0038 - CATracker and CA CRUD test > > > patch 0039 - extension to CA ACL test > > > patch 0040 - functional test with ACLs and certificate profile, reusing my > > > previous S/MIME based tests. This patch also tests for the cert-request > > > behavior when profile ID or CA cn are ommited. > > > > > > The tests ATM do not verify the Issuer name in the certificate itself, > > > just > > > from the ipa entry of the certificate. > > > > > The approach you are using:: > > > > assert cert_info['result']['issuer'] == smime_signing_ca.ipasubjectdn > > > > is not quite as you describe (these are virtual attributes, not > > attributes of an actual entry); but the approach is valid. > The issue then is in the wording? The other approach I could have used here > is to retrieve the two certificates and compare the fields manually. > Are these virtual attributes created from the certificate itself? > That's correct.
> > > > > Fraser, could you please verify my reasoning behind the test cases for > > > cert-request in the patch 40? > > > > > The tests look OK. With the default CA / default profiles, is there > > appropriate isolation between test cases to ensure that if, e.g. > > some other test case adds/modifies CA ACLs such that these > > expected-to-fail tests now pass, that this does not affect the > > TestCertSignMIMEwithSubCA test case? > > > > Thanks, > > Fraser > > The ACL, SMIME CA and S/MIME profile lifetime is constrained by the class > scope > enforced by pytest. > The two test cases depend on the fact documented in the designs and that is > what > cert-request fallbacks to when CA or profile ID are not provided. > Unless something changes caIPAserviceCert profile or affiliated ACL, then > the test cases > are safe. > If you have thought about possible interference from other tests, I am happy. Note another problematic scenario: what if a different (preceding) test adds a CA ACL that would allow the requests that you expect to fail? Just something to think about :) Thanks, Fraser > I will try to think more about corner cases here. > > > : http://www.freeipa.org/page/V4/Sub-CAs/Test_Plan > > > > > > Cheers > > > > > > -- > > > Milan Kubik > > > > Attaching rebased patches and removing the expected fail from one of the > tests as ticket 5981 has fix posted. > > -- > Milan Kubik > -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code