On Tue, Nov 10, 2009 at 8:22 AM, Davi Arnaut <Davi.Arnaut@stripped> wrote:
>
> On 11/7/09 2:14 PM, Phillip Moore wrote:
>
>> This is one of two areas where I'd like some feedback before reworking
>> the patch for submission. The pain introduced by changing an
>> exported function's signature doesn't seem worth it, since this has
>> been a stable interface for about 2 years or more. Therefore, I'm
>> suggesting a replacement function in order to maintain backwards
>> compatibility. Since apps that use this function will require code
>> changes to use a CRL anyway, this seems like the Right Thing.
>>
>> Therefore, I've concluded we need a new function, but what should it be
>> named?
>>
>> mysql_ssl_setup()
>> mysql_ssl_configure()
>>
>> If it were up to me, I'd pick the latter.
>
> Either one is fine. But how would this function work?
The new function would have an additional argument: ssl_crl. When
some one upgrades an application that calls mysql_ssl_set() to use SSL
CRLs, they will have to change from mysql_ssl_set to the new function,
which will have the additional argument.
I'll run with mysql_ssl_configure() for now.
>> That's it. Now, the next issue I have with this code is that the CRL
>> file is read into memory and the contents stashed in the SSL context
>> data structures when SSL is initialized. Unlike the ca, cert, and key
>> files, which are re-read for each connection, the CRL file is only
>> read once. If the CRL file is updated, then it requires a restart of
>> mysqld to take effect. All of the other SSL-related config files are
>> read dynamically when a connection is made.
>>
>> That's just wrong -- if updating one file takes effect in realtime,
>> updating ALL of the SSL files should take effect in realtime.
>> Requiring a server restart is so... 20th century. I think it makes
>> sense to re-read the CRL file and stash it in the SSL context data
>> prior to the authentication of each SSL connection, to ensure that the
>> file is read dynamically. I'm not entirely sure WHERE this should be
>> done in the code.
>
> It appears to be done in the right place. But it's all about trade offs,
> there is a penalty in reading a file for every new connection..
I just want the semantics of updating the SSL related config files to
be consistent. Right now, everything EXCEPT the CRL is read when
each connection is authenticated. It's just that one file that will
require a server restart.
I will find the right place in the code to read the CRL file and add
it to the SSL context so that the semantics of managing the SSL
configuration are consistent.
I guess my point is that the trade off should be made consistently in this case.
Anyway, thanks for the feedback. I lost my window of opportunity to
play with this, and will be revisiting MySQL's SSL support next month,
or maybe early next year at the latest.
