<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Greg,<br>
<br>
Thank *you* for the reminder!<br>
<br>
So as far as the GCE note, that's good to know. I'll put a note in
some of the documentation about this.<br>
<br>
In terms of it's relation to cloud.torproject.org... In a way this
pre-dates that, in a way it's new artwork. <br>
<br>
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.<br>
<br>
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.<br>
<br>
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"
(<a class="moz-txt-link-freetext" href="https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/">https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/</a>)
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).<br>
<br>
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.<br>
<br>
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.<br>
<br>
I'm happy to go into more detail, but I'm afraid it would bore the
majority of people on the mailing list.<br>
<br>
--Brian 'redbeard' Harrington <br>
<br>
<div class="moz-cite-prefix">On 03/13/2016 10:13 PM, Greg wrote:<br>
</div>
<blockquote
cite="mid:CAM8WWJADt5n0S3Qw=51xzVaGUZhg6p3vczRL+8_jh1aRKnb_eQ@mail.gmail.com"
type="cite">
<p dir="ltr"><br>
On Mar 11, 2016 3:51 AM, "nusenu" <<a moz-do-not-send="true"
href="mailto:nusenu@openmailbox.org">nusenu@openmailbox.org</a>>
wrote:<br>
><br>
> > This sounds like a great effort. I wanted to point out
2 things:<br>
> > 1) I think that GCE IP addresses are blacklisted (due
to an earlier sybil<br>
> > attack,<br>
> > <a moz-do-not-send="true"
href="https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html">https://lists.torproject.org/pipermail/tor-relays/2015-August/007656.html</a>).<br>
><br>
> I don't think it is blacklisted currently (but maybe
someone at the dir<br>
> auth level can confirm that), see also this tor-dev thread:<br>
><br>
> <a moz-do-not-send="true"
href="https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html">https://lists.torproject.org/pipermail/tor-dev/2015-August/009389.html</a></p>
<p dir="ltr">I just read that thread. Thanks for referencing my
issue back then! <br>
Greg</p>
<p dir="ltr">><br>
><br>
> > 2) How do you see your work relating to and differing
from the discontinued<br>
> > Tor Cloud (<a moz-do-not-send="true"
href="https://cloud.torproject.org/">https://cloud.torproject.org/</a>)
project? I don't mean to<br>
> > discourage you, but I'm curious what the differences
are.<br>
><br>
> <a moz-do-not-send="true"
href="http://cloud.torproject.org">cloud.torproject.org</a> is
dead.<br>
><br>
><br>
> _______________________________________________<br>
> tor-relays mailing list<br>
> <a moz-do-not-send="true"
href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a><br>
> <a moz-do-not-send="true"
href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a><br>
><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
tor-relays mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tor-relays@lists.torproject.org">tor-relays@lists.torproject.org</a>
<a class="moz-txt-link-freetext" href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays</a>
</pre>
</blockquote>
<br>
</body>
</html>