----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/8449/#review14290 -----------------------------------------------------------
/proton/trunk/proton-c/bindings/python/proton.py <https://reviews.apache.org/r/8449/#comment30439> Is there a reason this can't be done as a property like the rest of the API? /proton/trunk/proton-c/include/proton/ssl.h <https://reviews.apache.org/r/8449/#comment30440> Seems odd to call it a flag. Also, it should end in _t /proton/trunk/proton-c/include/proton/ssl.h <https://reviews.apache.org/r/8449/#comment30442> Maybe I'm missing something here, but isn't this backwards? Isn't the wildcard pattern actually contained in the wildcard certificate? Or is this something distinct from wildcard certificates, in which case, how does this interact with them? /proton/trunk/proton-c/include/proton/ssl.h <https://reviews.apache.org/r/8449/#comment30443> The API is a bit odd here. It seems like there is overlap, e.g. sometimes the match is against the hostname, and sometimes the match is against the hostname_match thingy. I'm also confused about the scenario in which we would ever need to supply a pattern against which to do a non-exact match. It seems like wildcard certificates would eliminate that need. I can see how maybe if you have a virtual server farm and you don't know which certificate you're going to get you might want to supply a pattern as the client, but I haven't ever heard of that as a standard pattern. (I'm not saying it isn't, I could just be ignorant here.) If it's not a standard pattern then maybe we should wait until a use case comes up to offer it? /proton/trunk/proton-c/src/ssl/openssl.c <https://reviews.apache.org/r/8449/#comment30441> I suggest we define our own function interface to do this kind of matching. We could implement it trivially on unix with fnmatch, and I beleive windows has similar API, but we could also just write our own impl if it's not available on windows. - Rafael Schloming On Dec. 10, 2012, 10:06 p.m., Kenneth Giusti wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/8449/ > ----------------------------------------------------------- > > (Updated Dec. 10, 2012, 10:06 p.m.) > > > Review request for qpid and Rafael Schloming. > > > Description > ------- > > Adds an API call to set the hostname which is used for Server Name Indication > as well as Common Name matching. Right now only support exact text match - > no wildcarding. > > > This addresses bug proton-161. > https://issues.apache.org/jira/browse/proton-161 > > > Diffs > ----- > > /proton/trunk/proton-c/bindings/python/proton.py 1419512 > /proton/trunk/proton-c/include/proton/ssl.h 1419512 > /proton/trunk/proton-c/src/ssl/openssl.c 1419512 > /proton/trunk/tests/proton_tests/ssl.py 1419512 > /proton/trunk/tests/proton_tests/ssl_db/README.txt 1419512 > /proton/trunk/tests/proton_tests/ssl_db/ca-certificate.pem 1419512 > /proton/trunk/tests/proton_tests/ssl_db/ca-private-key.pem PRE-CREATION > /proton/trunk/tests/proton_tests/ssl_db/client-certificate.pem 1419512 > /proton/trunk/tests/proton_tests/ssl_db/client-private-key.pem 1419512 > /proton/trunk/tests/proton_tests/ssl_db/server-certificate.pem 1419512 > /proton/trunk/tests/proton_tests/ssl_db/server-private-key.pem 1419512 > > Diff: https://reviews.apache.org/r/8449/diff/ > > > Testing > ------- > > Updated ssl unit tests. > > > Thanks, > > Kenneth Giusti > >
