Age | Commit message (Collapse) | Author |
|
|
|
Clamp year values returned by system localtime(_r) and
gmtime(_r) to year 1. This ensures tor can read any
values it might write out.
Fixes bug 13476.
|
|
Set the correct day of year value in correct_tm() when the
system's localtime(_r) or gmtime(_r) functions fail to set struct tm.
Fixes bug 13476.
|
|
This fixes bug 13102 (not on any released Tor) where using the
standard SSIZE_MAX name broke mingw64, and we didn't realize.
I did this with
perl -i -pe 's/SIZE_T_MAX/SIZE_MAX/' src/*/*.[ch] src/*/*/*.[ch]
|
|
This should stop a false positive from the clangalyzer.
|
|
Previously, we had documented it to return -1 or 0, when in fact
lseek returns -1 or the new position in the file.
This is harmless, since we were only checking for negative values
when we used tor_fd_seekend.
|
|
Closes ticket 12061. Based on a patch from "carlo von lynX" on tor-dev at
https://lists.torproject.org/pipermail/tor-dev/2014-April/006705.html
|
|
|
|
(Windows doesn't have ftruncate, and some ftruncates do not move the
file pointer to the start of the file.)
|
|
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
|
|
As far as I know, nobody has used this in ages. It would be a
pretty big surprise if it had worked.
Closes ticket 11446.
|
|
Conflicts:
src/common/include.am
|
|
In the unit tests I want to loop with a delay, but I want less than
a 1 second delay. This, sadly, requires compatibility code.
|
|
|
|
|
|
When running with User set, we frequently try to look up our
information in the user database (e.g., /etc/passwd). The seccomp2
sandbox setup doesn't let us open /etc/passwd, and probably
shouldn't.
To fix this, we have a pair of wrappers for getpwnam and getpwuid.
When a real call to getpwnam or getpwuid fails, they fall back to a
cached value, if the uid/gid matches.
(Granting access to /etc/passwd isn't possible with the way we
handle opening files through the sandbox. It's not desirable either.)
|
|
We'll use these to deal with being unable to access the user DB
after we install the sandbox, to fix bug 11946.
|
|
Fixes bug 11805; bugfix on 0.2.5.4-alpha.
|
|
|
|
|
|
Conflicts:
src/or/main.c
|
|
|
|
If we had an address of the form "1.2.3.4" and we tried to pass it to
tor_inet_pton with AF_INET6, it was possible for our 'eow' pointer to
briefly move backwards to the point before the start of the string,
before we moved it right back to the start of the string. C doesn't
allow that, and though we haven't yet hit a compiler that decided to
nuke us in response, it's best to fix.
So, be more explicit about requiring there to be a : before any IPv4
address part of the IPv6 address. We would have rejected addresses
without a : for not being IPv6 later on anyway.
|
|
(It's nice to know what we were about to rename before we died from
renaming it.)
|
|
(If we don't restrict rename, there's not much point in restricting
open, since an attacker could always use rename to make us open
whatever they want.)
|
|
|
|
|
|
|
|
|
|
|
|
This time, we use a pthread_attr to make sure that if pthread_create
succeeds, the thread is successfully detached.
This probably isn't the big thing going on with 4345, since it'd be
a bit weird for pthread_detach to be failing. But it's worth
getting it right.
|
|
Conflicts:
src/common/sandbox.c
|
|
|
|
Fix for bug 9400, spotted by coverity. Bug introduced in revision 2cb4f7a4
(subversion revision r389).
|
|
|
|
|
|
|
|
|
|
|
|
- Preserve old eventdns code.
- Add function to close sockets cross-platform, without accounting.
- Add changes/ file.
|
|
- char* to const char* and name refactoring
- workaround for accept4 syscall
|
|
|
|
|
|
|
|
|
|
This fixes bug 9047 (and some parts of 9031, 8922, 8883 that weren't
fixed in 8822). Bugfix on 0.2.2.6-alpha.
|
|
This reverts commit 884a0e269c382f9e927d8c8b1ef4ef9d2d48379d.
I'm reverting this because it doesn't actually make the problem go
away. It appears that instead we need to do unmap-then-replace.
|
|
|
|
A comment by rransom on #8795 taken together with a comment by doorss
recorded on #2077 suggest that *every* attempt to replace the md cache
will fail on Vista/Win7 if we don't have the FILE_SHARE_DELETE flag
passed to CreateFile, and if we try to replace the file ourselves
before unmapping it. I'm adding the FILE_SHARE_DELETE, since that's
this simplest fix. Broken indexers (the favored #2077 hypothesis)
could still cause trouble here, but at least this patch should make us
stop stepping on our own feet.
Likely fix for #2077 and its numerous duplicates. Bugfix on
0.2.2.6-alpha, which first had a microdescriptor cache that would get
replaced before remapping it.
|
|
|