Re: [tor-relays] Running 5000 relays...

[Greg <greggth@xxxxxxxxx>]

Brian,
That's all quite interesting. Thanks for sharing. I hope this work
goes well. It would help move Tor forward toward the cloud-based
software model that's becoming more and more popular.
Greg

On Mon, Mar 14, 2016 at 12:29 PM, Brian 'redbeard' Harrington
<redbeard@xxxxxxxxxx> wrote:
> Greg,
>
> Thank *you* for the reminder!
>
> So as far as the GCE note, that's good to know.  I'll put a note in some of
> the documentation about this.
>
> In terms of it's relation to cloud.torproject.org... In a way this pre-dates
> that, in a way it's new artwork.
>
> Many moons ago (~circa 2007) I was discussing this idea with Roger and Jake
> at the Non-profit Development Summit in Oakland.  Due to a number of factors
> (impostor syndrome, security concerns, etc) I abandoned the project
> convinced that someone else would do it.
>
> Moving on a number of years I never abandoned the idea.  In fact, in my mind
> it became a fantastic place to showcase some more recent work I've been
> involved with.
>
> Over the past two years I have been working with folks on a self-updating
> Linux distribution called CoreOS.  The important parts are that it's been
> massively stripped down (removing the attack surface), similar to old school
> Bell UNIX machines the /usr partition operates read only (think of the days
> of NFS mounted /usr), and the updates are atomically signed images including
> the kernel, systemd, sshd, glibc, and a very small number of other
> utilities.  All of these updates are pushed out using a mechanism called
> "Omaha protocol"
> (https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/) and
> images are pulled down, undergo GPG validation (and a few other checks) with
> an embedded key,and are processed.  All applications are run inside of Linux
> containers (systemd-nspawn, rkt, docker, doesn't really matter) to provide
> both a portable environment and process, mount, and network isolation (to
> the degree that the administrator chooses).
>
> With some of the more recent work, we've added GPG validation and TPM
> attestation of the container image as well.  This leads to a state where the
> user can guarantee that the applications executing on a host are attested by
> a known, trusted entity.m  In the short term we (CoreOS) must continue to
> demonstrate the utility of this.  One easy option is of course to provide
> usable applications atop the platform with a *need* to utilize these
> features.  In the long run it would be ideal if the "Tor developers" (in
> reality, the Tor release managers) could generate this container GPG signed
> giving users the ability to attest that the binaries have come "directly
> from the source".  This would then allow a user to download updates to the
> application and trust that the application came from an attested source.
>
> Back to how this works in practice, when a CoreOS update is processed it
> will reboot to pivot into the new user-land on disk.  This means that the
> application will temporarily go down, but state can maintained on disk.
> When the host gets back to a state with working networking it can look for
> an update to the application and pull it down (re-attesting it's source) and
> resume the running state of the application.
>
> I'm happy to go into more detail, but I'm afraid it would bore the majority
> of people on the mailing list.
>
> --Brian 'redbeard' Harrington
>
> On 03/13/2016 10:13 PM, Greg wrote:
>
>
> On Mar 11, 2016 3:51 AM, "nusenu" <nusenu@xxxxxxxxxxxxxxx> wrote:
>>
>> > This sounds like a great effort. I wanted to point out 2 things:
>> > 1) I think that GCE IP addresses are blacklisted (due to an earlier
>> > sybil
>> > attack,
>> >
>> > https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html).
>>
>> I don't think it is blacklisted currently (but maybe someone at the dir
>> auth level can confirm that), see also this tor-dev thread:
>>
>> https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html
>
> I just read that thread. Thanks for referencing my issue back then!
> Greg
>
>>
>>
>> > 2) How do you see your work relating to and differing from the
>> > discontinued
>> > Tor Cloud (https://cloud.torproject.org/) project? I don't mean to
>> > discourage you, but I'm curious what the differences are.
>>
>> cloud.torproject.org is dead.
>>
>>
>> _______________________________________________
>> tor-relays mailing list
>> tor-relays@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>>
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays