On Mon, Jul 17, 2006 at 02:46:07PM +0200, Jan Danielsson wrote: [...] > No offense taken. However, the wiki I was pointer to earlier in this > thread is a bit to flammable for my tastes. From > http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ServerOS: > > "[---] If you want to run a Tor server, we recommend you upgrade to a > better OS." > > Although this wiki is linked to from the TOR site, I am unsure if it > is an official TOR wiki, so this may be off-topic. I am also not sure if > the quote above is meant to say "[...] a better OS [for running a TOR > server]" or "[...] a better OS [period!]". If the latter is intended, I > suggest someone change it, because I don't feel that a TOR wiki is the > place for OS advocacy. As noted, it's a wiki, so you can change it. As an alternative to "better," I'd suggest "more up-to-date" or "more thread-friendly" or "more appropriate". > Also, the statement is pointless in the sense that I highly doubt > that many users are about to switch operating system just to run TOR. I > may be wrong, but I know I certainly wouldn't -- even though I very much > am a supporter of what TOR is trying to accomplish. > > Anyway, even if OS advocacy wasn't intended, it's still pretty > flammable, imho. It would be better to mention that in NetBSD-current, > the gethostbyname_r() problems should be fixed. Can you confirm this with a link? Better yet, can you alter the wiki to say the right thing? > Or mention other > possible future directions which may work around such problems, and ask > for help from the BSD community. > > > OpenBSD claims to have a gethostbyname_r, but it is > > lying: it just #defines gethostbyname_r to gethostbyname. (This is > > the moral equivalent of keeping your rat poison in a jar labeled > > "cookies".) > > I know.. I have used API:s which I though were reentrant and mt-safe > but turned out not to be. It was an "interesting" exercise, as in "what > an interesting brain tumor you have". But in my case it wasn't > mislabeled; it was my own fault for not reading the document > introduction properly. <off-topic rant>This is actually _worse_ in the OpenBSD case. The only reason to provide gethostbyname_r in addition to gethostbyname is that _r is supposed to be reentrant. All standards and documentation say so. There's no reason to provide a _r that isn't reentrant, unless you want to confuse people who use autoconf to try to find a reentrant gethostbyname(). This is just a bad decision on the implementors' part, period.</> > >> As a side note, I don't understand why the calls to gethostbyname() > >> can't be mutex'd on BSD systems, rather than just switching over to an > >> all fork'd design. Are there other calls which are affected as well? > > > > We _could_ go multithreaded and make it block, but performance on exit > > nodes would suck. When two users wanted to make exit connections at > > the same time, one wouldn't start a DNS lookup until the other was > > done. Also, an attacker could shut down all DNS requests just by > > making requests that would take a long time to complete. > > Ah, obviously. I never even thought of DNS lookups as being slow. :-/ Oh, it happens. All you need is one domain with slow DNS for the attack to work. > > Right now, we're trying a different approach. In version 0.1.2.x, > > we're trying an approach where we add a built-in async DNS resolver to > > Tor and don't use the platform DNS resolver at all: this way, we don't > > need to be multithreaded. Right now, it seems to have a bug that > > creates a periodic segfault, but watch this space: I hope we'll get it > > straightened out soon. > > Oh, so the actual code (+ bug) is already there? Neat. I'll take a > look. Is a new release, with built in DNS resolver, planned for the near > future? It's in CVS; feel free to check it out? It's very much alpha, so it probably won't be an official non-alpha release for the next couple of months at least. yrs, -- Nick Mathewson
Attachment:
pgpfkNw0IzvNb.pgp
Description: PGP signature