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 [1] 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.
> > > [1]: 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

Reply via email to