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.

Jacob Appelbaum authored 14 years ago and Nick Mathewson committed 14 years ago

 * 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

Jacob Appelbaum authored 14 years ago and Nick Mathewson committed 14 years ago

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.

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.

These options only work when using --with-(openssl|libevent)-dir to
explicitly pick a libevent or openssl location.

mfwitten authored 15 years ago and Nick Mathewson committed 15 years ago

The following commit:

    commit e56747f9
    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]

Nathan Freitas authored 15 years ago and Nick Mathewson committed 15 years ago

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).

In tor-resolve, when the Tor client to use is specified by <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

svn:r17610

Change logging code to use fds instead of stdio.  Fixes bug 861, and 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

svn:r17002

svn:r16776

svn:r16663

svn:r16662

svn:r16658

svn:r16657

 Split out the address manipulation functions from compat and util: they were about 21% of the total of those, and spread out too much.


svn:r16208

 New (temporary) tool to dump the modulus of a key.  May help with a project of weasel's.


svn:r14580

svn:r14152