[tor-project] Cloud Compute Resources for Tor Browser

[Georg Koppen]

Tom Ritter:
> On 18 August 2017 at 17:15, Roger Dingledine <arma at mit.edu> wrote:
>> On Fri, Aug 18, 2017 at 01:45:58PM -0700, Shari Steele wrote:
>>> Thanks for bringing this to my attention.  I'm going to respond to you privately to help clarify this some more.
>>
>> The alternative is that we get dedicated computers from Hetzner, and
>> pay ~$100/mo for Tor Browser build machines. I think we have something
>> like two of those that we pay for right now: one for Windows builds,
>> and one for Tor Messenger builds, and we've been talking about getting
>> a third to help the Tor Browser team do builds.
>>
>> It's not clear to me whether getting the Hetzner computer is the better
>> or worse idea. There's the price tradeoff; also maybe we're looking for
>> different security goals, e.g. between sandbox developer computers vs
>> official build machines; and maybe the Cloud image is easier for people
>> to work with. But in an ideal world, we would pick the better idea and
>> stop needing to do the worse one. :)
> 
> I don't think we should trust these for security much at all, only for
> testing or untrusted development. But you can do a lot on an untrusted
> development box.
> 
> Price is then the one axis, the other access is accessibility. The
> advantage of EC2 is that when we publish the development image, anyone
> who wants to contribute to Tor Browser and is willing to pay their own
> cost can get a pre-set up dev environment that they know will compile
> correctly (and quickly). That's advantageous. I don't know if Hetzner
> has anything similar. (And we can spin up more with zero
> configuration, and revert with zero effort.)
> 
> That said, I tried to do this a long time ago before reproducible
> builds with a Windows AMI, and I don't think anyone used it. Maybe
> because it was Windows, maybe I'm just overestimating the willingness
> of the community to pay for a machine to get a working dev env.

What you experienced is one of the things that make me skeptical as well.

However, I think I'd like to make a more general point as well. There
are actually only two reasons why one wants to have such an elaborate
development setup

1) Making sure the code builds reproducibly
2) Making sure it compiles with all our toolchains

Thus, "normal" patch development should be largely unaffected by having
such a developmen environment. We try to point that out on our Tor
Browser hacking page by explaining how to just work with the Firefox
part and test the patch in an Tor Browser environment. One of the ideas
behind that was to make the entry barrier to browser development as low
as possible: no special AWS stuff that one needs to use, no need to wait
on a ton of patch-unrelated things to get built before seeing the
results of the patch, no need to setup the reproducible build environment.

I think I like to keep that approach for the casual Tor Browser patch
dev. The question then boils down what to do with the final test of the
patch both regarding 1) and 2) mentioned above.

For the GSoC case you mentioned it is perfectly fine for me if one of us
gives the proposed patches a final whirl on the dev environments we
already have to test that they compile and don't touch the
reproduciblity property. Yes, i agree we should not bother the student
with setting up a reproducible builds environment on a machine they have
access to. But spinning up, and maintaining such an image and paying for
these services just for that case seems a bit overkill to me.

Now what about the casual Tor Browser patch writer? I am not sure but
recalling past experiences (which are not many) I've never heard that
writing Tor Browser patches failed because someone did not have access
to a reproducible build system. What we did was basically the
GSoC-student related approach mentioned above which happened during code
review and it worked out so far. Sure it's hard to estimate how many
potential devs got scared away by seeing the complex build system and
might have stayed had they access to some preconfigured image. But the
solution to that should be, in the first place, to make our wiki clearer
about the barriers to development being much lower.

So, all in all I am a bit skeptical about whether the time and money we
would spend are spent best the way you envision.

Georg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20170823/0d7097e0/attachment.sig>