On Thu, Jul 17, 2014 at 6:42 AM, Arturo Filastò art@torproject.org wrote:
Hi Least Authoritarians,
Thanks for the report. I will be away until the 30th of July so I will not be able to resolve these issues until that date.
I will reply inline.
On 7/16/14, 11:44 PM, Nathan Wilcox wrote:
---------- Forwarded message ---------- From: Taylor Hornby taylor@leastauthority.com Date: Wed, Jul 16, 2014 at 2:42 PM Subject: Ooni / M-Lab Deployment Automation Script
All of these tickets, with the exception of #40, #12641, #41, #42, and #44 are now closed. Ticket #40 is a minor issue, but would involve significant design decisions on M-Lab's part, so we left it open for M-Lab to close. Ticket #12641 is about the use of a deprecated function in Ooni, to be fixed by the Ooni team. Ticket #42 is about a missing dependency in Ooni for the Ooni team to fix. Ticket #44 is about a security vulnerability that requires Ooni collaboration to resolve (see below).
I will look more into #12641 and see if it is something that can be fixed in ooni-backend, but from the looks of it it seems like a twisted bug.
We don't use the IStreamClientEndpointStringParser interface at all and I see some other projects on the internet having the same issue:
For the time being I'm not aware of any functional or security problem, just an annoying warning message.
We also found a new security vulnerability in Ooni:
#12642: Can Network Attacker Downgrade Dependency Install Security? https://trac.torproject.org/projects/tor/ticket/12642#ticket
As I commented on the ticket I believe that there is not so much we can do here except perhaps improve the documentation of ooni-backend.
I thought it was clear from the README.md that the user should verify that all the commands that are run do not fail. If the pip command fails, because it did not download a dependency, then you are correct it is possible for an attacker to serve us a tampered dependency.
One thought is to hack "python ./setup.py install" to execute the pip command internally, but I'm not at all sure that's sane yet.
This has to do with the fact that python dependency installation is quite broken.
No disagreement here. ;-)
In fact, several different projects are attempting to do similar things to Ooni here, so I'm hoping some better tools emerge. I've heard peep attempts to do something better than pip for installing only verified dependencies...
The script in the mlab support should check for the return value of pip and make sure it's 0 and if not hard fail.
Agreed. Whereas this issue for ooni is kind of about enhancement or improvement to make it more robust, for ooni-support it's an outright bug:
https://github.com/m-lab-tools/ooni-support/issues/44
For non mlab deployment I think the best path is to start uploading ooni-backend to pip and suggest to install it only via pip without downloading the git repo.
+1
I am a fan of this distribution target / instructions in general for modern python. However, there are cases where end-users need to be able to securely install dependencies from tarballs, git clones, etc...
I'd love to learn why "pip install ." doesn't do the right thing, or how to prevent "python ./setup.py install" from doing the wrong thing, but neither of those tasks is on my likely-to-be-completed queue, at the moment.
~ Art. _______________________________________________ ooni-dev mailing list ooni-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-dev