Bug#766306: torsocks: ERROR torsocks[13827]
Hi David,
unfortunately, the fix for #766306 (fd passing) makes torsocks fail to
build on kfreebsd-{amd64,i386}:
https://buildd.debian.org/status/package.php?p=torsocks
May you please have a look?
Time-wise, I'd like to see this bug fixed in Jessie, and the deadline
to have a fix for an important bug is December 5, so it would be
good to have a fix that doesn't introduce regressions by, say,
November 20. Does it look doable to you?
Cheers,
--
intrigeri
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
Please reply on #768140, sorry for the confusion. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
Control: severity -1 important Control: tag -1 + pending Hi, David Goulet wrote (23 Oct 2014 13:15:02 GMT) : On reason it might fail, this test needs Tor access thus the Internet :). Indeed, that was it -- thanks! The test passes for me when I give network access to my pbuilder build environment. I'm now testing a 2.0.0-2 tentative package with this patch applied. If it works fine for me, then I'll upload tomorrow. Bumping severity, after discussing it with Lunar (who leaned the other way) and making up my mind: on the one hand, not supporting some usecases in torsocks is entirely acceptable; on the other hand, aborting an application altogether, which can cause data loss, is no good way to communicate your usecase is not supported to a torsocks user. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
Hi David, David Goulet wrote (22 Oct 2014 21:06:16 GMT) : Just pushed the update in the upstream git. https://gitweb.torproject.org/torsocks.git/commit/eb80d5cd10d10158b39c344ad035afe8d31a899f That commit *improves* drastrically Unix socket fd passing detection and adds a test also. I've been using it for the last hours, I'm confident that you can package it. Worst case, we'll issue a fix quickly :). Thanks. This new test doesn't pass for me (with that commit applied on top of Debian's 2.0.0-1): ./test_fd_passing Failed 5/5 subtests Does it depend on any other unreleased commit on your master branch, or something? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
On 23 Oct (08:02:36), intrigeri wrote: Hi David, David Goulet wrote (22 Oct 2014 21:06:16 GMT) : Just pushed the update in the upstream git. https://gitweb.torproject.org/torsocks.git/commit/eb80d5cd10d10158b39c344ad035afe8d31a899f That commit *improves* drastrically Unix socket fd passing detection and adds a test also. I've been using it for the last hours, I'm confident that you can package it. Worst case, we'll issue a fix quickly :). Thanks. This new test doesn't pass for me (with that commit applied on top of Debian's 2.0.0-1): ./test_fd_passing Failed 5/5 subtests Does it depend on any other unreleased commit on your master branch, or something? Hrm! No... I ran that test for an full hour in a loop yesterday and it *never* failed the full 5 sub-tests... On reason it might fail, this test needs Tor access thus the Internet :). Other way to find out what's failing, can you simply run it and provide the output? TORSOCKS_LOG_LEVEL=5 ./tests/test_fd_passing Thanks! David signature.asc Description: Digital signature
Bug#766306: torsocks: ERROR torsocks[13827]
Hi David, tester wrote (22 Oct 2014 04:08:42 GMT) : I was running bitmessage, and figured out it really isnt using the proxy, so I ran it using torsocks, it ran for along time, but then crashed with this error after I posted a message ERROR torsocks[13827]: [recvmsg] Inet socket passing detected. Aborting everything! A non Tor socket could be used thus leaking information. (in tsocks_recvmsg() at recv.c:87) Does this ring a bell? Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
On 22 Oct (11:07:02), intrigeri wrote: Hi David, tester wrote (22 Oct 2014 04:08:42 GMT) : I was running bitmessage, and figured out it really isnt using the proxy, so I ran it using torsocks, it ran for along time, but then crashed with this error after I posted a message ERROR torsocks[13827]: [recvmsg] Inet socket passing detected. Aborting everything! A non Tor socket could be used thus leaking information. (in tsocks_recvmsg() at recv.c:87) Does this ring a bell? 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. 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. Cheers! David Cheers, -- intrigeri signature.asc Description: Digital signature
Bug#766306: torsocks: ERROR torsocks[13827]
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
Bug#766306: torsocks: ERROR torsocks[13827]
On 22 Oct (16:29:28), intrigeri wrote: 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? Poor code is *very* widespread in the world unfortunately... However, application using fd passing are usually a bit more resilient since it's not a trivial feature to use and many errors are possible! I think that once we detect FD passing (if inet), we could stop it, close the passed socket and return something like EACCESS. This is not documented in the man page unfortunately but Linux LSM return that error code if denied (I just confirmed with the kernel code) so I think it would be a good alternative. In a nutshell, cleanup the received socket and return EACCESS? If we agree on that, I can push a patch today! David Cheers! -- intrigeri signature.asc Description: Digital signature
Bug#766306: torsocks: ERROR torsocks[13827]
David Goulet wrote (22 Oct 2014 14:42:14 GMT) : In a nutshell, cleanup the received socket and return EACCESS? If we agree on that, I can push a patch today! I'm lacking the basic knowledge needed to clearly understand everything about this proposal, but your reasoning looks sensible, so... go! :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
On 22 Oct (17:01:29), intrigeri wrote: David Goulet wrote (22 Oct 2014 14:42:14 GMT) : In a nutshell, cleanup the received socket and return EACCESS? If we agree on that, I can push a patch today! I'm lacking the basic knowledge needed to clearly understand everything about this proposal, but your reasoning looks sensible, so... go! :) I guess you prefer an official release for that? signature.asc Description: Digital signature
Bug#766306: torsocks: ERROR torsocks[13827]
David Goulet wrote (22 Oct 2014 15:19:58 GMT) : I guess you prefer an official release for that? A commit applied to your HEAD would be enough, as long as it's well tested. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766306: torsocks: ERROR torsocks[13827]
On 22 Oct (22:29:43), intrigeri wrote: David Goulet wrote (22 Oct 2014 15:19:58 GMT) : I guess you prefer an official release for that? A commit applied to your HEAD would be enough, as long as it's well tested. Just pushed the update in the upstream git. https://gitweb.torproject.org/torsocks.git/commit/eb80d5cd10d10158b39c344ad035afe8d31a899f That commit *improves* drastrically Unix socket fd passing detection and adds a test also. I've been using it for the last hours, I'm confident that you can package it. Worst case, we'll issue a fix quickly :). Cheers! David Cheers, -- intrigeri signature.asc Description: Digital signature
Bug#766306: torsocks: ERROR torsocks[13827]
Package: torsocks Version: 2.0.0-1 Severity: normal Dear Maintainer, I was running bitmessage, and figured out it really isnt using the proxy, so I ran it using torsocks, it ran for along time, but then crashed with this error after I posted a message ERROR torsocks[13827]: [recvmsg] Inet socket passing detected. Aborting everything! A non Tor socket could be used thus leaking information. (in tsocks_recvmsg() at recv.c:87) thanks for your work :D *** End of the template - remove these template lines *** -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages torsocks depends on: ii libc6 2.19-11 Versions of packages torsocks recommends: ii tor 0.2.5.8-rc-1 torsocks suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
