fix compatibility with C99

Closes #40014

See merge request !9

configure.ac: update version to 2.4.0

See merge request !8

In getaddrinfo:

* use default hints when none supplied
* never request v4-mapped addresses
* never let libc's getaddrinfo do network lookups

See merge request !7

This is an extra safeguard to ensure it will never try to do a network
lookup.

Tor doesn't support connecting to them, so don't ask for them.
tor#40611

Previously we fell back to libc's getaddrinfo when hints is NULL, under
the mistaken assumption that the default address family AF_UNSPEC would
guarantee it wouldn't look up any address. It's actually the opposite -
it means v4 and v6 are both acceptable.

On my machine the previous behavior the native call to getaddrinfo makes
an interceptible call to `socket` to create a UDP socket which we block,
preventing a leak, but it's possible with other libc's this could have
caused a leak.

With this change such calls can still potentially succeed and return
addresses, resolved via tor.

Changelog for 2.4.0

See merge request !6

Disable ipv6 socket creation by default

Closes #40009

See merge request !5

IPv6 support is incomplete. Some programs (e.g. signal-cli) fail with
the current IPv6 support, but gracefully fall back to IPv4 if we refuse
to create an IPv6 socket in the first place.

Fixes #40009

Delegate to libc fclose in error cases

See merge request !4

The native fclose can succeed in spite of not having a valid fd
associated with it.
#40002 (comment 2803789)

Fix typos

See merge request !3

Merges !2

Ola Bini authored Jul 09, 2020 and David Goulet committed Oct 27, 2020

Since the original flags are not taken into account when peeking, the peek
recvmsg call will hang forever in certain circumstances, including in all QT
applications running Wayland. This fix simply adds the original flags, so that
the peeking recvmsg call might be nonblocking, if the original call was
nonblocking.

Closes #40001

Signed-off-by: David Goulet <dgoulet@torproject.org>

Originating from: https://bugzilla.redhat.com/show_bug.cgi?id=1601259

Patch by "cHBWyJuH".

Fixes #26794



Signed-off-by: David Goulet <dgoulet@torproject.org>

It gets really noisy with mutt. Not sure why, I expect maybe multi
thread/process makes it that everytime it dies, we get that log statement.

Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes #25627



Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes #25586



Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes #24081



Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes #23876



Signed-off-by: David Goulet <dgoulet@torproject.org>

Whatever we use IPv4 or IPv6, make torsocks use the configured SocksPort in
the configuration.

Signed-off-by: David Goulet <dgoulet@torproject.org>

The other IP doesn't work anymore and I can't recall what it was ;).

Signed-off-by: David Goulet <dgoulet@torproject.org>

Because of the SafeSocks parameter of Tor, if set, we can't pass a raw IP
address to Tor since it will believe we did a DNS resolution from the
application.

Now, thanks to #22461, Tor safely accepts an IPv4/IPv6 address withing a FQDN
connect request which avoids the SafeSocks warnings.

The #22461 wasn't backported which means that torsocks working with SafeSocks
is only possible in tor >= 0.3.2 stable series.

Fixes #23667



Signed-off-by: David Goulet <dgoulet@torproject.org>

Fixes #22068



Signed-off-by: David Goulet <dgoulet@ev0ke.net>

Fixes #17618

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

Enough things use this now, that the syscall(2) wrapper should support
it, since glibc doesn't provide a wrapper for it, and the documentation
says to invoke it using syscall(2).

Also, replace spaces for a tab.

Signed-off-by: David Goulet <dgoulet@ev0ke.net>

Signed-off-by: David Goulet <dgoulet@ev0ke.net>