| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
libnatpmp-20110618 changed the API that tor-fw-helper used and for a time
tor-fw-helper could not build against the newest libnatpmp. This patch brings
support for libnatpmp to tor-fw-helper.
|
|
|
|
It used to mean "Force": it would tell tor-resolve to ask tor to
resolve an address even if it ended with .onion. But when
AutomapHostsOnResolve was added, automatically refusing to resolve
.onion hosts stopped making sense. So in 0.2.1.16-rc (commit
298dc95dfd8), we made tor-resolve happy to resolve anything.
The -F option stayed in, though, even though it didn't do anything.
Oddly, it never got documented.
Found while fixing GCC 4.6 "set, unused variable" warnings.
|
|
|
|
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
|
|
|
|
Having very long single lines with lots and lots of things in them
tends to make files hard to diff and hard to merge. Since our tools
are one-line-at-a-time, we should try to construct lists that way too,
within reason.
This incidentally turned up a few headers in configure.in that we were
for some reason searching for twice.
|
|
|
|
|
|
|
|
* MINIUPNPC rather than the generic UPNP
* Nick suggested a better abstraction model for tor-fw-helper
* Fix autoconf to build with either natpmp or miniupnpc
* Add AM_PROG_CC_C_O to fix automake complaint
* update spec to address nickm's concern
* refactor nat-pmp to match upnp state
* we prefer tor_snprintf to snprintf
* link properlty for tor_snprintf
* rename test_commandline_options to log_commandline_options
* cast this uint as an int
* detect possible FD_SETSIZE errors
* make note about future enhancements for natpmp
* add upnp enhancement note
* ChangeLog entry
* doxygen and check-spaces cleanup
* create tor-fw-helper.1.txt
|
|
tor-fw-helper is a command-line tool to wrap and abstract various
firewall port-forwarding tools.
This commit matches the state of Jacob's tor-fw-helper branch as of
23 September 2010.
(commit msg by Nick)
|
|
This should make us conflict less with system files named "log.h".
Yes, we shouldn't have been conflicting with those anyway, but some
people's compilers act very oddly.
The actual change was done with one "git mv", by editing
Makefile.am, and running
find . -name '*.[ch]' | xargs perl -i -pe 'if (/^#include.*\Wlog.h/) {s/log.h/torlog.h/; }'
|
|
|
|
Works like the --enable-static-openssl/libevent options. Requires
--with-zlib-dir to be set. Note that other dependencies might still
pull in a dynamicly linked zlib, if you don't link them in statically
too.
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
On Windows, we don't have a notion of ~ meaning "our homedir", so we
were deliberately using an #ifdef to avoid calling expand_filename()
in multiple places. This is silly: The right place to turn a function
into a no-op on a single platform is in the function itself, not in
every single call-site.
|
|
This is so that coverity stops complaining about using a user-supplied
string with the open() syscall. Let's see if it works.
|
|
Resolved conflicts in:
configure.in
src/or/Makefile.am
src/tools/Makefile.am
|
|
These options only work when using --with-(openssl|libevent)-dir to
explicitly pick a libevent or openssl location.
|
|
The following commit:
commit e56747f9cf29ed788baf8805bfe391925d8a19da
Author: Nick Mathewson <nickm@torproject.org>
Date: Tue Dec 15 14:32:55 2009 -0500
Refactor a bit so that it is safe to include math.h, and mostly not needed.
introduced this line:
tor_resolve_LDADD = -lm ../common/libor.a @TOR_LIB_WS32@
which caused the build to fail, because only ../common/libor.a
(via the embedded ../common/util.o via ../common/util.c)
referenced libm's `lround' and `log' symbols, so that the
linker (GNU ld) didn't bother to import those symbols before
reading ../common/libor.a, thus leaving those symbols undefined.
The solution was to swap the order, producing the line:
tor_resolve_LDADD = ../common/libor.a -lm @TOR_LIB_WS32@
Signed-off-by: Michael Witten <mfwitten@gmail.com>
|
|
|
|
Previously, tor-gencert would call RSA_generate_key() directly.
This won't work on Android, which removes the (deprecated since
OpenSSL 0.9.8) function. We can't call RSA_generate_key_ex()
unconditionally either, since that didn't exist before 0.9.8.
Instead, we must call our own crypto_pk_generate_key_with_bits,
which knows how to call RSA_generate_key or RSA_generate_key_ex as
appropriate.
[Based on patch by Nathan Freitas]
|
|
This shouldn't be necessary, but apparently the Android cross-compiler
doesn't respect -I as well as it should. (-I is supposed to add to the
*front* of the search path. Android's gcc wrapper apparently likes to add to
the end. This is broken, but we need to work around it.)
|
|
|
|
Big thanks to nickm and arma for helping me with this!
|
|
|
|
If the Tor is running with AutomapHostsOnResolve set, it _is_
reasonable to do a DNS lookup on a .onion address. So instead we make
tor-resolve willing to try to resolve anything. Only if Tor refuses
to resolve it do we suggest to the user that resolving a .onion
address may not work.
Fix for bug 1005.
|
|
This patch adds a new compat_libevent.[ch] set of files, and moves our
Libevent compatibility and utilitity functions there. We build them
into a separate .a so that nothing else in src/commmon depends on
Libevent (partially fixing bug 507).
Also, do not use our own built-in evdns copy when we have Libevent
2.0, whose evdns is finally good enough (thus fixing Bug 920).
|
|
|
|
|
|
|
|
<hostname>:<port>, actually use the specified port rather than defaulting to 9050
svn:r18833
|
|
svn:r18478
|
|
The subversion $Id$ fields made every commit force a rebuild of
whatever file got committed. They were not actually useful for
telling the version of Tor files in the wild.
svn:r17867
|
|
implementation of proposal 157.
svn:r17610
|
|
probably makes logging slightly faster. Not a backport candidate: bug 861 is too obscure and harmless.
svn:r17456
|
|
an obscure compile warning on solaris
svn:r17453
|
|
syntax.
svn:r17002
|
|
svn:r16776
|
|
svn:r16663
|
