Branch :
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
| 6171e1c2 | 2013-08-13 18:19:50 | sample: drop uri_root from base_url in http-server. By default there is "0.0.0.0", and this address will work only from the same machine, and besides there is no need in uri_root in base_url, because it will be added automatically by browser. | ||
| 44b2491b | 2013-08-06 19:23:36 | sample/le-proxy: Fail more gracefully if opening listener fails | ||
| eb6b0c1f | 2013-04-25 10:47:16 | Merge branch '21_evdns_disable_when_inactive' | ||
| 6b7fa620 | 2013-03-27 20:15:46 | evdns: New flag to make evdns not prevent the event loop from exiting Here is the brief description of problem: When you are use evdns to resolve domains to IP adresses (see ./sample/dns-example) you loop never returns from event_base_dispatch(), and because of this the program will never terminated. Because existing programs may be depending on the old behavior, we only apply the fix when evdns_base_new() is created with a new flag - EVDNS_BASE_DISABLE_WHEN_INACTIVE. (Commit message edited by Nick while squashing the branch.) | ||
| 95acdaa3 | 2013-04-10 17:56:54 | Another tweak to https-client.c | ||
| 8a90a850 | 2013-04-10 13:53:44 | Remove http_struct.h usage in sample/https-client.c | ||
| 4db9da6b | 2013-02-27 21:12:53 | pull in wildcard matching code from cURL Now, https-client accepts both: https://ip.appspot.com/ (matching wildcard certificate) https://github.com/ (matching non-wildcard certificate) but still rejects https://www.kegel.com/ (non-matching wildcard certificate) which should match the behavior of these sites in a web browser. | ||
| 6021cb50 | 2013-02-27 21:19:16 | avoid sign mismatch warning in openssl_hostname_validation.c sample/openssl_hostname_validation.c: In function 'matches_common_name': sample/openssl_hostname_validation.c:80: warning: comparison between signed and unsigned integer expressions sample/openssl_hostname_validation.c: In function 'matches_subject_alternative_name': sample/openssl_hostname_validation.c:124: warning: comparison between signed and unsigned integer expressions | ||
| 64d9f161 | 2013-02-27 17:16:27 | use iSECPartners code to validate hostname in certificate The problem is that if you go to a website whose certificate does not match its hostname, it should fail. Try this in a web browser for https://www.kegel.com/ for example. Your web browser will say the certificate is for *.pair.com, not for www.kegel.com, and won't let you visit it without clicking through a bunch of scary warnings. However, prior to this commit, https-client was happy to fetch https://www.kegel.com/ without complaining. That is bad. Now, with this commit, it will properly complain, which is good: pelletier@chives:~/src/libevent/sample$ ./https-client https://www.kegel.com/ Got 'MatchNotFound' for hostname 'www.kegel.com' and certificate: /C=US/postalCode=15203/ST=Pennsylvania/L=Pittsburgh/street=Suite 210/street=2403 Sidney Street/O=pair Networks, Inc./OU=Provided by pair Networks, Inc./OU=PairWildcardSSL $250,000/CN=*.pair.com some request failed - no idea which one though! error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ppelletier@chives:~/src/libevent/sample$ It will still succeed for sites with an exactly-matching certificate, such as https://github.com/ and that is also good! However, the problem is that the iSECPartners code doesn't handle wildcards, which means we reject https://ip.appspot.com/ even though it is perfectly legitimate, because we don't understand the wildcard: ppelletier@chives:~/src/libevent/sample$ ./https-client https://ip.appspot.com/ Got 'MatchNotFound' for hostname 'ip.appspot.com' and certificate: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.appspot.com some request failed - no idea which one though! error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ppelletier@chives:~/src/libevent/sample$ So, we need to fix this. In other words, "to be continued..." | ||
| aacd674c | 2013-02-26 00:06:50 | use Debian's default root certificate location as suggested here: http://archives.seul.org/libevent/users/Feb-2013/msg00034.html although curl's acinclude.m4 reveals many other possibilities: dnl /etc/ssl/certs/ca-certificates.crt Debian systems dnl /etc/pki/tls/certs/ca-bundle.crt Redhat and Mandriva dnl /usr/share/ssl/certs/ca-bundle.crt old(er) Redhat dnl /usr/local/share/certs/ca-root.crt FreeBSD dnl /etc/ssl/cert.pem OpenBSD dnl /etc/ssl/certs/ (ca path) SUSE And none of these cover Windows :( |