| Age | Commit message (Collapse) | Author |
|---|
|
Also, have tor_disable_debugger_attach() return a tristate of
success/failure/don't-know-how , and only log appropriately.
|
|
Also fix a comment typo
|
|
Modifies filenames which do not start with '/' or '.' on non-Windows
platforms; uses _fullpath on Windows.
|
|
|
|
Fixes bug 4535; bugfix on 0.2.2.28-beta; found by "troll_un"
|
|
|
|
This slipped through into 0.2.3.8-alpha unfortunately.
|
|
In particular:
* Disallow "0x10::"
* Don't blow up on ":"
* Disallow "::10000"
|
|
The of-by-one error could lead to 1 byte buffer over runs IPv6 for addresses.
|
|
|
|
Thanks to funkstar for the report
|
|
|
|
|
|
I'm not one to insist on C's miserly stack limits, but allocating a
256K array on the stack is too much even for me.
Bugfix on 0.2.1.7-alpha. Found by coverity. Fixes CID # 450.
|
|
|
|
|
|
Conflicts:
src/common/compat.c
src/or/main.c
|
|
On win64, sockets are of type UINT_PTR; on win32 they're u_int;
elsewhere they're int. The correct windows way to check a socket for
being set is to compare it with INVALID_SOCKET; elsewhere you see if
it is negative.
On Libevent 2, all callbacks take sockets as evutil_socket_t; we've
been passing them int.
This patch should fix compilation and correctness when built for
64-bit windows. Fixes bug 3270.
|
|
|
|
|
|
|
|
Conflicts in various places, mainly node-related. Resolved them in
favor of HEAD, with copying of tor_mem* operations from bug3122_memcmp_022.
src/common/Makefile.am
src/or/circuitlist.c
src/or/connection_edge.c
src/or/directory.c
src/or/microdesc.c
src/or/networkstatus.c
src/or/router.c
src/or/routerlist.c
src/test/test_util.c
|
|
bug3122_memcmp_022
Conflicts throughout. All resolved in favor of taking HEAD and
adding tor_mem* or fast_mem* ops as appropriate.
src/common/Makefile.am
src/or/circuitbuild.c
src/or/directory.c
src/or/dirserv.c
src/or/dirvote.c
src/or/networkstatus.c
src/or/rendclient.c
src/or/rendservice.c
src/or/router.c
src/or/routerlist.c
src/or/routerparse.c
src/or/test.c
|
|
Here I looked at the results of the automated conversion and cleaned
them up as follows:
If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I
changed it to a fast_memcmp or fast_memeq.
Otherwise if there was a tor_memcmp that could turn into a
tor_memneq or tor_memeq, I converted it.
This wants close attention.
[*] I'm erring on the side of caution here, and leaving some things
as tor_memcmp that could in my opinion use the data-dependent
fast_memcmp variant.
|
|
This commit is _exactly_ the result of
perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch]
perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch]
perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch]
git checkout src/common/di_ops.[ch]
git checkout src/or/test.c
git checkout src/common/test.h
|
|
|
|
|
|
|
|
|
|
These functions can return NULL for otherwise-valid values of
time_t. Notably, the glibc gmtime manpage says it can return NULL
if the year if greater than INT_MAX, and the windows MSDN gmtime
page says it can return NULL for negative time_t values.
Also, our formatting code is not guaranteed to correctly handle
years after 9999 CE.
This patch tries to correct this by detecting NULL values from
gmtime/localtime_r, and trying to clip them to a reasonable end of
the scale. If they are in the middle of the scale, we call it a
downright error.
Arguably, it's a bug to get out-of-bounds dates like this to begin
with. But we've had bugs of this kind in the past, and warning when
we see a bug is much kinder than doing a NULL-pointer dereference.
Boboper found this one too.
|
|
Trivial Conflicts in
src/common/crypto.c
src/or/main.h
src/or/or.h
|
|
About 860 doxygen-less things remain in 0.2.2
|
|
|
|
Once again spotted by mobmix
Also add a changes file for the fix
|
|
|
|
Patch our implementation of tor_lockfile_lock() to handle this case
correctly. Also add a note that blocking behaviour differs from windows
to *nix. Fixes bug 2504, issue pointed out by mobmix.
|
|
|
|
Conflicts:
src/common/test.h
src/or/test.c
|
|
|
|
|
|
Conflicts:
src/common/memarea.c
src/or/or.h
src/or/rendclient.c
|
|
This will avoid some signed/unsigned assignment-related bugs.
|
|
It's all too easy in C to convert an unsigned value to a signed one,
which will (on all modern computers) give you a huge signed value. If
you have a size_t value of size greater than SSIZE_T_MAX, that is way
likelier to be an underflow than it is to be an actual request for
more than 2gb of memory in one go. (There's nothing in Tor that
should be trying to allocate >2gb chunks.)
|
|
|
|
I don't know if any platforms we care about don't have FD_CLOEXEC,
but this is what we do elsewhere
|
|
Conflicts:
src/or/relay.c
|
|
On windows, it's called something different.
|
|
|
|
|
|
|
