[ooni-dev] Fwd: Ooni / M-Lab Deployment Automation Script

[Nathan Wilcox]

On Thu, Jul 17, 2014 at 6:42 AM, Arturo Filastò <art at 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 at 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:
>
> https://github.com/getsentry/raven-python/issues/466
>

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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/ooni-dev



-- 
Nathan Wilcox
Least Authoritarian

email: nathan at leastauthority.com
twitter: @least_nathan
PGP: 11169993 / AAAC 5675 E3F7 514C 67ED  E9C9 3BFE 5263 1116 9993