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" <nus...@openmailbox.org > <mailto:nus...@openmailbox.org>> 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 <http://cloud.torproject.org> is dead. > > > > > > _______________________________________________ > > tor-relays mailing list > > tor-relays@lists.torproject.org <mailto:tor-relays@lists.torproject.org> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > > _______________________________________________ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
