Nov 21 2017
Jul 9 2017
The diff looked very weird. Somehow you reverted to an earlier version of bindp.c. Fixed in master.
git clone firstname.lastname@example.org:Whonix/bindp.git cd bindp git checkout bindppost make deb-icup
If the goal is simply put the libindp.so file into /usr/lib, I think I was successful. @Patrick If it tests fine for you, please merge to master and close this ticket.
Jul 8 2017
JasonJAyalaP (Jason J. Ayala P.):
It doesn't remove the .c file.
There was a dh-helper warning. Something about #dh-helper# token not being in bindp.postinst. I'm not what to do there.
JasonJAyalaP (Jason J. Ayala P.):
JasonJAyalaP added a comment.https://github.com/Whonix/bindppost
git clone email@example.com:Whonix/bindppost.git cd bindppost make deb-icup
Jul 3 2017
A miracle has happened. All of https://github.com/yongboy/bindp/pull/6 was merged by upstream.
Very well. So finally they applied our patch.
Jun 16 2017
Agreed. If they really want to stick to i686 then they can if they know what they are doing. Otherwise I don't think its a good use of time to support this officially. especially with the recent changes for the KVM version where its just easier to delete and start over.
@Patrick In the master branch the only difference in comparison to the original version that I can see is the main function at the bottom of the file. Did you not apply the changes? This code is still the previous one.
Btw this ticket will probably result in users of Non-Qubes-Whonix 13 (i686) being able to upgrade to Non-Qubes-Whonix 14. @HulaHoop
Due to T599#13695...
Merged into master.
Jun 15 2017
For reference, the (relevant, i think) flags that bindp make currently uses:
Jun 5 2017
Mar 26 2017
Mar 10 2017
Do you see any things a malicious application could to gain arbitrary code execution through bindp?
Mar 9 2017
Notified upstream. Let's see if he replies.
Functionally speaking, as I tested, it works great in Whonix. Pretty much done.
@Patrick Do you have anything else from this project remained that needs extra working on ?
Works for me!
Mar 8 2017
Onionshare 0.9.1 | https://onionshare.org/ [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged [!] connect(): AF_INET connect() call [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged [!] connect(): AF_INET connect() call [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged [!] connect(): AF_INET connect() call [-] LIB received AF_INET bind request [-] Changing 127.0.0.1 to 10.137.11.80 [-] AF_INET: Leaving port unchanged Can't connect to Tor control port on port [9151, 9153, 9051]. OnionShare requires Tor Browser to be running in the background to work. If you don't have it you can get it from https://www.torproject.org/.
Added that. And added some intent style changes. Please tell me if my C intent style is actually making things non-standard / worse than before.
Why did you add #ifdef SO_REUSEPORT?
Well the segfault error is strange here, I must run it locally with your setup to check and debug which is not possible for now, but it's good you made it work finally. Good job Patrick. Still I think PIE related options are not needed for libraries.
I will modify the code by tonight and send the new revisions.
Mar 7 2017
It's functional! Successfully changes the listener IP.
That's great! Thank you for your help! Just now tested. Unfortunately it does not work.
@Patrick Nice, now regular testing needs to be done from your side, please keep in mind that connect function has to change as well, but before that I must assure that current bind() works properly and as expected. If everything goes well I will write whole code from scratch for you by modifying init and connect functions.
Mar 6 2017
What does DSO mean?
Can we have all hardening with PIE enabled as well as without ld warning?
@Patrick You can compile without -fPIE (I think -fPIC is enough):
Do you know how to fix these compiler warning?