Closed jcavar closed 6 years ago
Yes, that is correct.
So you can set property streamSSLLevel
of MQTTCFSocketTransport
to what you want. I am just wondering if there is enough info in the comments there for people to figure this one out or should we start thinking at some spare time about handling docs for this
Also I thought github would link this PR to https://github.com/novastone-media/MQTT-Client-Framework/issues/423
You are actually right, I will list possible values in header doc.
I am now thinking about leaving kCFStreamSocketSecurityLevelNegotiatedSSL
as default value because that is what it was before. Would that make more sense?
This is "whatever server is using"?
Also what's up with the broken build?
Kind of:
Specifies that the highest level security protocol that can be negotiated be set as the security protocol for a socket stream.
Some flaky tests doing a lot of stuff. I will need to investigate that separately.
Yes, then kCFStreamSocketSecurityLevelNegotiatedSSL
should be a default one. In this/next year we'll start to see wider adoption of TLSv1.3
as well so we should not prescribe a specific version but use the best one possible.
Regards tests, we can speak to that at some other time, maybe I am just reading the logs wrong :) is there a bug # for that I could subscribe to?
But it is not because of missing submodules? As I read it, all tests that were run have passed
No, in this case something is weird with output, it is cut off as far as I can tell.
You're right. When you visit through the build log you get the full output, so the MQTTTestSessionManager
test suite is broken. This also could be related to https://github.com/novastone-media/MQTT-Client-Framework/issues/422 but I digress.
Regards this PR I think we're done unless you want to bring Pablo up to speed on this one.
This is meant to be configurable right?