On Fri, Sep 10, 2010 at 1:03 AM, James Jackson <[email protected]> wrote: > > Hi all, > > Just testing the water for if a patch would be welcome... We plan to run > replication on remote sites, which must be authenticated via SSL certificates > (X.509). I believe to do this requires very minimal changes. As an > un-compiled, un-tested example, something like the following: > > In couch_rep.erl: > > do_init([RepId, {PostProps}, UserCtx] = InitArgs) -> > ... > % Parse SSL certificate options > TmpCert = couch_config:get("ssl", "replication_certfile", nil), > TmpKey = couch_config:get("ssl", "replication_keyfile", nil), > SSLParams = case {TmpCert, TmpKey} of > {nil, nil} -> []; > {nil, _} -> []; > {_, nil} -> [], > {C, K} -> [{ssl_options, [{certfile, C}, {keyfile, K}]}] > end, > > ProxyParams = parse_proxy_params( > couch_util:get_value(<<"proxy">>, PostProps, [])), > > Source = open_db(SourceProps, UserCtx, ProxyParams, SSLParams), > Target = open_db(TargetProps, UserCtx, ProxyParams, SSLParams, > CreateTarget), > ... > > Note that all open_db functions now need an extra SSLParams parameter. > Alternatively, this could be tacked-on the the ProxyParams list, but then the > name doesn't make sense... In couch_rep_httpc.erl: > > open_db({Props}, _UserCtx, ProxyParams, SSLParams, CreateTarget) -> > ... > Db = Db1#http_db{options = Db1#http_db.options ++ ProxyParams ++ > SSLParams}, > ...
Seems good to me. Please fill in a ticket with a patch and I'll review it. > > I believe ibrowse should now take care of everything from hereon in. I note > that there is a patch from Monday which fixes a possible certificate > authentication security hole > (https://issues.apache.org/jira/browse/COUCHDB-878), which also deals with > ssl-related things in couch_rep_httpc.erl. This certificate functionality, > and the SSL verification from the patch, could be wrapped as a > 'make_ssl_opts' function. > > Additionally, I see that in db_exists, the calls to ibrowse:send_req do not > pass the options from the #http_db record; surely this means that the proxy > (if specified), and the SSL authentication, if implemented as above, will not > be used for the initial PUT / HEAD requests? It's definitely a bug. I'll correct it asap. cheers > > Regards, > James. -- Filipe David Manana, [email protected], [email protected] "Reasonable men adapt themselves to the world. Unreasonable men adapt the world to themselves. That's why all progress depends on unreasonable men."
