Nick Mathewson wrote: > [...] >> I'd rather like to find a real solution to the problem. Mainly, >> getting a working gethostbyname_r(). Btw.. What is the origin of >> gethostbyname_r()? Does it exist in all common/mainstream unicies? > > Pretty much, except for the (I hope you'll forgive the term) less > popular BSDs. 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. 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. 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. >> 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. :-/ > 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? -- Kind regards, Jan Danielsson
Attachment:
signature.asc
Description: OpenPGP digital signature