On 03/13/2013 08:18 PM, Nick Mathewson wrote:
Oh, this is going to be a *fun* one!
Yeah, I was afraid of that.
Here's a brain-dump. I'm not an expert on Windows APIs, so there may
be errors or omissions.
Thanks for the brain dump! I'm afraid I'm in the same boat; I'm a Linux
programmer
I was perusing whatsnew-2.0.txt and saw:
Libevent 2.1 may add a multithreaded WaitForMultipleEvents-based
backend for better performance with many inactive sockets and better
integration with Windows events.
Although that hasn't been added yet, I was wondering if anyone had
thought about
On 03/07/2013 08:51 AM, Nick Mathewson wrote:
Thanks! Is there no way to do this *without* importing a big pile of
code from curl? That seems kinda extreme.
We could go back to Catalin's original, which accepts certificates that
don't match the host. It guess it's a question of what an examp
On 02/27/2013 10:22 PM, Patrick Pelletier wrote:
But now, without further ado, here is my branch which takes Catalin's
original https-client.c, fixes a few small issues (or things which I
considered issues in my opinion), and finally adds the hostname
checking. I structured it as a numb
ger problems before it can build
this sample. I may have to look into that at a later date.)
The following changes since commit 87c56727b61e48c102d21f1bb6477de8ec001869:
Nick Mathewson (1):
Merge pull request #41 from ppelleti/winsock-errs
are available in the git repository at:
On 02/20/2013 07:26 PM, Jardel Weyrich wrote:
There's X509_check_host for that, but I'm really not sure whether it's
enough or not.
Please correct me if I'm mistaken, but my impression is that
X509_check_host only exists in the OpenSSL trunk, but has not yet
appeared in any released version
I recently went through a similar experience of trying to get evhttp to
work as a client with IPv6. This evolved in the thread "evhttp client
error handling". Some of the most important posts in the thread are:
http://archives.seul.org/libevent/users/Nov-2012/msg00015.html
http://archives.seu
I noticed the following comment in evutil_socket_error_to_string in
evutil.c:
/* Is there really no built-in function to do this? */
The answer is yes, the built-in function FormatMessage will do this for
you. I'm happy to submit a patch that will change
evutil_socket_error_to_string to
Azat Khuzhin wrote:
It looks like that you don't have ipv6 support, maybe kernel module
don't loaded.
Try to test like this
$ ls /proc/net/if_inet6
No, I definitely have IPv6 support. That is how this came up in the
first place: "localhost" on my machine resolves to both "::1" and
"127.0.0.
post you code somewhere? If you don't want to show all of
it, you could write 20-40 lines, that can reproduce this problem.
About retries: could you send backtrace when this messages are printed?
Thanks.
On Thu, Jan 24, 2013 at 7:36 AM, Patrick Pelletier
wrote:
On 01/22/2013 02:54 PM, Az
On 01/22/2013 02:54 PM, Azat Khuzhin wrote:
Could you try to test my patch
https://github.com/azat/libevent/commit/71e709c7829275a594f767b27468b1b52e8b5bb9.patch
and write if it works for you?
Thanks, I think that's a step in the right direction.
However, I'm still having trouble. My callba
Azat Khuzhin wrote:
Also on which operating system did you work?
Ubuntu 10.04 LTS:
Linux chives 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC
2011 x86_64 GNU/Linux
But the operating system doesn't really matter. This is a general
problem with evhttp, regardless of OS.
Maybe
On 11/19/2012 06:48 AM, Nick Mathewson wrote:
On Thu, Nov 15, 2012 at 2:32 AM, Patrick Pelletier
mailto:ppellet...@oblong.com>> wrote:
[...]
Not sure what the proper solution is for this, though. I'm not
enough of a sockets expert. Although I'm curious why we need t
On 12/10/2012 03:05 AM, Patrick Pelletier wrote:
There is a SSL_CTX_set_cert_verify_callback,
but the iSECPartners document says very strongly never to use it, at the
bottom of page 2:
https://github.com/iSECPartners/ssl-conservatory/blob/master/openssl/everything-you-wanted-to-know-about
On 12/10/2012 03:05 AM, Patrick Pelletier wrote:
So I had been thinking it couldn't be done with the callback. However,
after re-reading the manpage for SSL_CTX_set_verify, it sounds like it
does get called on success, and is given the opportunity to fail the
connection. So perhaps I
Nick Mathewson wrote:
I'm pretty sure John is asking about UDP support under bufferevents.
That's nontrivial.
The last time I looked, it appeared that the socket-backed
bufferevent code was almost exactly right for a UDP transition, but
that the underlying evbuffer objects didn't have a lot of
Oscar Koeroo wrote:
The SSL_CTX_set_verify and SSL_CTX_set_verify_callback are used to validate
the certificate (chain) itself. Useful when OpenSSL triggers a
false-negative on a certificate chain, you have your own extensions build-in
the certificate (think: Microsoft PKI in their deployments or
I've been writing an https client using OpenSSL and libevent 2.1.2,
using this example as a basis:
http://archives.seul.org/libevent/users/Mar-2012/msg00014.html
and it's mostly doing what I want now. However, one thing I still need
to do is check that the certificate has the correct hostname
On 11/13/2012 09:48 PM, Patrick Pelletier wrote:
So, I figured out that the initial error that's occurring is
EAFNOSUPPORT. (Now, why that's happening is a separate mystery I need
to figure out... it happens when I use "localhost" as the hostname,
but not when I use &quo
On 11/01/2012 09:13 PM, Patrick Pelletier wrote:
Anyway, the error stack does seem to be empty, because
"ERR_print_errors_fp (stderr);" does not print anything. So, that
means I should look at errno, which is ENOTCONN.
So, I figured out that I shouldn't be looking at the OpenS
I'm attempting to write an https client using evhttp and
libevent_openssl. It's not working, and I'm not so much concerned about
that in itself (I'm sure I'm doing something wrong with OpenSSL; that is
par for the course), but I'm trying to figure out how to get evhttp to
tell me what the erro
On 07/04/2012 08:07 AM, Dave Hart wrote:
Have you tried providing OPENSSL_DIR in the environment to nmake?
set OPENSSL_DIR=c:\openssl
nmake
or on its command line:
nmake OPENSSL_DIR=c:\openssl
My guess is either approach will work.
Thanks, both of these work, and I've updated the comment i
On 06/08/2012 09:18 PM, Patrick Pelletier wrote:
I've also taken it a bit further, and added support for OpenSSL to
Makefile.nmake. Unfortunately, I don't know nmake very well (I haven't
yet looked up how to do conditionals, for example), so my Makefile.nmake
is very hacked up ri
Nick Mathewson wrote:
Is the monotonic_fallback failure consistent, or does it only happen
some of the time?
It seems to be consistent. But I'm doing this on a virtual machine, and
I know time is often funny on VMs.
--Patrick
**
On 06/08/2012 01:55 PM, Nick Mathewson wrote:
Looks like I never added evutil_time.c to Makefile.nmake when I added
it to Makefile.am. Should be fixed in 0ba0683bcfc8652a8c50.
Thanks; that works for me!
I've also taken it a bit further, and added support for OpenSSL to
Makefile.nmake. Unfo
On 06/06/2012 05:18 PM, Patrick Pelletier wrote:
(since libEvent doesn't seem to have an equivalent to
OpenSSL's "applink.c" that bridges between the two compilers' runtimes)
(I'd sure like to have one of those, fwiw.)
If that's something you'd
On 06/06/2012 06:57 AM, Nick Mathewson wrote:
(since libEvent doesn't seem to have an equivalent to
OpenSSL's "applink.c" that bridges between the two compilers' runtimes)
(I'd sure like to have one of those, fwiw.)
If that's something you'd like, then I might look into that as an
alternati
Sorry if this is a frequently asked question, but I haven't been able to
find an answer in the documentation or mailing list archives.
My ultimate goals are:
- I'd like to use libEvent from an application built with Visual C++ 2010
- I'd like libEvent to be a DLL (not a static library)
- I want
28 matches
Mail list logo
