There was actually a bug in the original version of this: it tried to
run the finalizers after (potentially) setting current_base to NULL;
but those finalizers could themselves (potentially) be invoking stuff
that needed to know about the current event_base. So the right time to
do it is _before_ clearing current_base.
Since the bufferevents' events are now EV_FINALIZE (name pending),
they won't deadlock. To clean up properly, though, we must use the
finalization feature.
This patch also split bufferevent deallocation into an "unlink" step
that happens fast, and a "destruct" step that happens after
finalization.
More work is needed: there needs to be a way to specify a finalizer
for the bufferevent's argument itself. Also, this finalizer business
makes lots of the reference counting we were doing unnecessary.
Also, more testing is needed.
The fix was easy: the tests that were failing were those tests that
also enabled debug mode themselves. So, let them know when
EVENT_DEBUG_MODE is on, so they won't do that.
It is useful to know why you callback called with NULL (i.e. it failed),
for example if you set max_body with evhttp_connection_set_max_body_size()
you must know that it failed because of body was longer than this size.
(Commit message tweaked by Nick)
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.)
When resuming the system from a suspended state, the ev_timeout field
of a scheduled timer event may be in the past. This leads to
unexpected behavior when scheduling a short-duration timer event
immediately after returning from suspension, because the new event
does not land on top of the timeout minheap and so the event loop
(blocked on a possibly long-duration timeout) is not notified.
This patch checks for this condition and, if it obtains, notifies the
event loop.
This patch add check in evhttp_decode_uri_internal() that next 2 symbols
are exists in array of chars for decoding, if don't have two next 2
symbols don't try to decode '%FF'
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.
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
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..."
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 :(
presumably this was meant to put a ">" before every line, but that
isn't what it does, since evbuffer_remove is simply returning
fixed-size chunks. So, when retrieving a document of more than 256
bytes (e. g. any nontrivial document), we got "> " and newlines thrown
in at very arbitrary places.
This made the difference between segfaulting and not segfaulting for
me when I run https-client, when I've built libevent using an OpenSSL
in a non-standard location.
In the same spirit as 1d9d5110a4aebf5833f6fd78bd0252affde0f4d0 and
d70af27d0152d0a87a25127faf215604beb8ffe0.
