| Age | Commit message (Collapse) | Author |
|---|
|
|
|
If a hostname is supplied to tor-resolve which is too long, it will be
silently truncated, resulting in a different hostname lookup:
$ tor-resolve $(python -c 'print("google.com" + "m" * 256)')
If tor-resolve uses SOCKS5, the length is stored in an unsigned char,
which overflows in this case and leads to the hostname "google.com".
As this one is a valid hostname, it returns an address instead of giving
an error due to the invalid supplied hostname.
|
|
They broke stem, and breaking application compatibility is usually a
bad idea.
This reverts commit 6e10130e18c80f4521e31b071455ae0b1bbea761,
commit 78a13df15842e8ab262e17825160386fadb77056, and
commit 62f52a888acc191bcb507d27d31d54e42e6effdd.
We might re-apply this later, if all the downstream tools can handle
it, and it turns out to be useful for some reason.
|
|
|
|
|
|
|
|
|
|
The paths are already in the directory search path of the compiler therefore no
need to include them in the source code.
|
|
Resolves 14325
|
|
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
Conflicts:
src/tools/tor-resolve.c
|
|
Fixes bug 13295; bugfix on 0.2.5.3-alpha.
The alternative here is to call crypto_global_init() from tor-resolve,
but let's avoid linking openssl into tor-resolve for as long as we
can.
|
|
(And replay them once we know our first real logs.)
This is an implementation for issue 6938. It solves the problem of
early log mesages not getting sent to log files, but not the issue of
early log messages not getting sent to controllers.
|
|
Bugfix on 96b1bd4fb8e64. Not in any released Tor.
|
|
This shouldn't actually matter, since tor-resolve will return soon
after this function exits, but it's nice to be warning-free
Found by coverity, fixes CID 718633
|
|
|
|
|
|
|
|
|
|
This commit is completely mechanical; I used this perl script to make it:
#!/usr/bin/perl -w -i.bak -p
if (/^\s*\#/) {
s/MS_WINDOWS/_WIN32/g;
s/\bWIN32\b/_WIN32/g;
}
|
|
Now let's have "lookup" indicate that there can be a hostname
resolution, and "parse" indicate that there wasn't. Previously, we
had one "lookup" function that did resolution; four "parse" functions,
half of which did resolution; and a "from_str()" function that didn't
do resolution. That's confusing and error-prone!
The code changes in this commit are exactly the result of this perl
script, run under "perl -p -i.bak" :
s/tor_addr_port_parse/tor_addr_port_lookup/g;
s/parse_addr_port(?=[^_])/addr_port_lookup/g;
s/tor_addr_from_str/tor_addr_parse/g;
This patch leaves aton and pton alone: their naming convention and
behavior is is determined by the sockets API.
More renaming may be needed.
|
|
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
|
|
|
|
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/; }'
|
|
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
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.
|
|
|
|
<hostname>:<port>, actually use the specified port rather than defaulting to 9050
svn:r18833
|
|
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
|
|
probably makes logging slightly faster. Not a backport candidate: bug 861 is too obscure and harmless.
svn:r17456
|
|
syntax.
svn:r17002
|
|
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
|
|
Refactor log domain mask code so that nobody outside of log.c has to use SEVERITY_MASK_IDX. It is error-prone.
svn:r14016
|
|
Implement domain-selection for logging. Source is documented; needs documentation in manpage (maybe). For now, see doxygen comment on parse_log_severity_config in log.c
svn:r13875
|
|
svn:r13412
|
|
Fix some hard to trigger but nonetheless real memory leaks spotted by an anonymous contributor. Needs review. Partial backport candidate.
svn:r13147
|
|
add init_logging calls to tor_gencert and tor_resolve
svn:r13028
|
|
svn:r12786
|
|
Patch from sjmurdoch to fix dnsleak warning when reverse-resolving via socks5.
svn:r11373
|
|
Include fewer redundant headers; use the compiler search paths better.
svn:r11060
|
