Hi, David Goulet wrote (22 Oct 2014 13:22:14 GMT) : > Yes. That means torsocks detected that the torified process received an > inet socket from an other process using the fd passing feature of Unix > socket thus stopped everything since it can't torify that socket.
Thanks for the explanation :) > I thought about a middle groud of simply denying the call and returning > an error but still printing an error. > Let me know if you would be open to try that. I can provide a trivial > patch quickly for testing. I'm not sure what would be best for user experience. The problem with aborting the torsocks'ified application altogether is that it can result in data loss -- right? If that's the case, then this bug is actually release critical, and indeed the way you're suggesting seems to be the way to go. In order to have it in Jessie without needing to go through the unblock request process, we would have to upload a fix in the next 2 days. OTOH, merely returning+printing an error could be confusing, if the application is poorly written and doesn't check the return value. I guess that's someone else's problemâ„¢, but actually we have to care a little bit, and I've no idea how widespread such problems can be in the real world. Any idea? Cheers! -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org