Tickets :: Comment on [#13730] Implementation of peer verification in TLS connections

* Your Email Address
* Spam protection	Enter the letters below: .__ . ..__..__ __. [__)\ /\| \|[__)(__ \| \/ \|__\|[__).__)
Comment	> I see the point that an independent library must not rely on horde's > configuration. However, I see no point in storing the same > information multiple times. As long as the Socket Client library is > used within horde, horde's configuration will be available. Therefore > this information should be used if its available. > > For those who do not want to store the information for peer > verification globally or those who use the library idependently from > horde, I implemented the possibility to override the information in > $GLOBALS. > > === How does it work? === > There is a new parameter named $tls_params. As far as I can see there > is no use for $params, but since I am not familiar with horde's code > I avoided to use it. $tls_params may be used to override the > parameters from $GLOBALS['conf']['openssl']. Whene > $tls_params['source'] is set to 'override', $GLOBALS will not be used > in any case, even if no other values in $tls_params are given. > Otherwise every given configuration will be used, whereas $tls_params > overrules $GLOBALS. > > === Benefits === > The global configuration will be used if it is available. If it is > not available or the peer verification is not configured the libraray > works as before, which means the peers will not be verified. $GLOBALS > can be overwritten or disabled by $tls_params. > > === Regressions === > The library will not change in behavior until a deliberate change by > an admin running the horde installation is made. As long as the peer > verification is not enabled globally and $tls_params is not set > during instantiation of a client object, the peer verification will > be disabled as it was until now. So, there should be no regressions.
Attachment
Watch this ticket

Saved Queries