| Age | Commit message (Collapse) | Author |
|---|
|
Add magic comments recognized by default -Wimplicit-fallthrough=3
or break, as required.
|
|
|
|
|
|
|
|
This helps protect against bugs where any part of a buf_t's memory
is passed to a function that expects a NUL-terminated input.
It also closes TROVE-2016-10-001 (aka bug 20384).
|
|
This commit adds or improves the module-level documenation for:
buffers.c circuitstats.c command.c connection_edge.c control.c
cpuworker.c crypto_curve25519.c crypto_curve25519.h
crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
protover.c protover.h reasons.c rephist.c replaycache.c
routerlist.c routerparse.c routerset.c statefile.c status.c
tor_main.c workqueue.c
In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it. In a few cases, I've added TODO
notes about refactoring opportunities.
I've also renamed an argument, and fixed a few DOCDOC comments.
|
|
Also, add tests for the function.
Closes 20081; bugfix on 0.2.0.16-alpha. This is a Guido Vranken
issue. Thanks, Guido!
|
|
|
|
These functions were there so that we could abstract the differences
between evbuffer and buf_t. But with the bufferevent removal, this
no longer serves a purpose.
|
|
|
|
|
|
Signed-off-by: U+039b <*@0x39b.fr>
|
|
So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"
But we have a huge pile of such comments accumulated for a large
number of released versions! Not cool.
So, here's what I tried to do:
* 0.2.9 and 0.2.8 are retained, since those are not yet released.
* XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
quite important!"
* The others, after one-by-one examination, are downgraded to
plain old XXX. Which doesn't mean they aren't a problem -- just
that they cannot possibly be a release-blocking problem.
|
|
|
|
|
|
|
|
|
|
This patch was generated using;
sed -i -e "s/\bINLINE\b/inline/" src/*/*.[ch] src/*/*/*.[ch]
|
|
Thanks to Roger for spotting this!
|
|
I was going to add a test for this, but I realized that it had no
users. So, removed.
|
|
|
|
|
|
Also, add some sample tests to be examples.
|
|
The paths are already in the directory search path of the compiler therefore no
need to include them in the source code.
|
|
|
|
|
|
|
|
|
|
This fixes an assertion failure bug in 15083; bugfix on 0.2.0.10-alpha.
Patch from 'cypherpunks'
|
|
They have been off-by-default since 0.2.5 and nobody has complained. :)
Also remove the buf_shrink() function, which hasn't done anything
since we first stopped using contiguous memory to store buffers.
Closes ticket 14848.
|
|
|
|
Supposedly there are a decent number of applications that "support"
IPv6 and SOCKS5 using the FQDN address type. While said applications
should be using the IPv6 address type, allow the connection if
SafeSocks is not set.
Bug not in any released version.
|
|
Conflicts:
src/or/or.h
src/test/Makefile.nmake
|
|
Conflicts:
src/or/buffers.c
|
|
|
|
|
|
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
|
|
Cases that now send errors:
* Malformed IP address (SOCKS5_GENERAL_ERROR)
* CONNECT/RESOLVE request with IP, when SafeSocks is set
(SOCKS5_NOT_ALLOWED)
* RESOLVE_PTR request with FQDN (SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED)
* Malformed FQDN (SOCKS5_GENERAL_ERROR)
* Unknown address type (SOCKS5_ADDRESS_TYPE_NOT_SUPPORTED)
Fixes bug 13314.
|
|
|
|
I'd prefer not to use the name "send" for any function that doesn't
really send things.
|
|
unsupported request.
|
|
while testing
|
|
|
|
When maintaining buffer freelists, we don't skip more than there
are, so (*chp) can't be null to begin with. scan-build has no way
to know that.
|
|
|
|
Conflicts:
src/common/compat_libevent.h
src/or/relay.c
|
|
Conflicts:
src/or/relay.c
|
|
In a couple of places, to implement the OOM-circuit-killer defense
against sniper attacks, we have counters to remember the age of
cells or data chunks. These timers were based on wall clock time,
which can move backwards, thus giving roll-over results for our age
calculation. This commit creates a low-budget monotonic time, based
on ratcheting gettimeofday(), so that even in the event of a time
rollback, we don't do anything _really_ stupid.
A future version of Tor should update this function to do something
even less stupid here, like employ clock_gettime() or its kin.
|
