[Twisted-Python] The role of twisted.internet._sslverify.IOpenSSLTrustRoot

Glyph Lefkowitz glyph at twistedmatrix.com
Fri Dec 25 19:32:21 MST 2015


> On Dec 25, 2015, at 2:35 PM, meejah <meejah at meejah.ca> wrote:
> 
> Glyph Lefkowitz <glyph at twistedmatrix.com> writes:
> 
> (Thanks for the review, Adi!)
> 
>> On Dec 20, 2015, at 9:05 AM, Adi Roiban <adi at roiban.ro> wrote:
> 
>>> It it documented as a private interface, it has only private methods,
>>> but then it is exposed in twisted.internet.ssl.optionsForClientTLS
>>> Why?
> 
>> Yes, this is intentional.  It is a private interface, so you can't
>> check if something provides it, you aren't allowed to know what
>> attributes it has, and you can't implement it.
> 
> So in the context of #7671 and testing, can the tests for multiTrust()
> just check that they get an IOpenSSLTrustRoot implementation back or do
> ... something else? That is, currently I'm just confirming this via
> asserting IOpenSSLTrustRoot.providedBy(theReturnValue) or so in the
> tests. Of course, this means I'm importing the private interface into
> the tests...

Twisted's own tests may always feel free to import private implementation details if they're useful for testing.

However, ideally, the tests for multiTrust ought to pass along a fake OpenSSL context object and ensure the correct methods are called on it; you can do this without importing any private API, just public API from pyOpenSSL and public API from Twisted, but it does involve a bit more set-up.  There are, however, lots of examples of doing that setup, particularly in test_sslverify (which already has a FakeContext).  So if you can, please do it that way.

Thanks!

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/twisted-python/attachments/20151225/badb3247/attachment-0002.html>


More information about the Twisted-Python mailing list