Hi,
no-reply@??? wrote (14 Apr 2012 18:17:06 GMT) :
> jvoisin has updated the proposal to named Tails Server at
> http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/jvoisin/29002:
Thank you.
> (The petname system for Tor hidden services project would be very
> complementary to this one, by the way.)
Reference needed.
> Another fancy way would be to use dropbear plus avahi, but since
> deploying avahi involve some intricate firewall configuration in the
> Tails context, I don't think it fits into this project's scope.
Really?
> 1. Check configuration presence
> When Tails boots, it will at some point check for the presence of
> a storage media containing a Tails server configuration.
What kind of marker makes this possible is left to be thought through.
> 2.1 Advertising on the LAN
> Tails-server needs to advertise his presence and location on the
> LAN. The less worth manner is to use avahi/zeroconf.
> 2.2 LAN
> Since the most common setup is a LAN with a modem/router provided by the ISP, they
> contains at least one untrusted machine. So MITM attacks are likely to happen; this
> is why we need to be able to authenticate the server. Doing so require that the
> client carry some informations about the server (certificates, and.or ssh keys).
... and the server to carry some private information about itself.
> 2.3 Dropbear
> A possible solution would be to take advantage of the
> cryptsetup/dropbear integration in debian to boot encrypted (but
> /boot) system. The client would log using ssh into tails-server, and
> enter the passphrase using a custom shell which is roughly
> a passphrase-prompt. Even if this solution is the easiest to
> implement, it is not (like the following one) very user friendly.
Why silently dismiss the "Unlock remote Tails server" GUI solution
that was suggested?
> 2.5 Authentication
> Self signed certificates do more harms than good, since they scare
> the user because of the browser warning. But, because tails-server
> can only be created from tails, generated certificates fingerprint
> could be stored in a ~/.tails-server folder : Any certificates found
> there would be added to iceweasel on as soon as Tails has opened the
> persistent volume and found this preset.
I think you should make it clear when you're talking of the client
authenticating the server, and when you're talking of the contrary.
> Ssh public key must be stored too, and written in the
> ~/.ssh/known_hoss of the server.
I don't think so. Are you talking of client or server public keys?
> Configuration management
> Service configuration requires a nice way to handle the
> configuration files in order to avoid a complete disparate mess.
> In an ideal world, every services configurations should be handled
> by debconf.
There's still no word to explain what exact problem (upgrades, etc.)
we're trying to solve here.
> Most likely the debconf approach way will be postponed to the Wheezy
> + 1 Debian release(probably in 3 years).
Note that this is the (expected) release date, which is long after the
time work should start for the needed debconf options to be ready in
time for Wheezy+1. Starting one year before looks like a bare minimum.
> Tails server configuration GUI
> I'll do the Tails server configuration GUI if time permits, probably
> in pyGTK, to make it easy to extend and maintain. The configuration
> GUI should provided services configuration, since the persistence
> USB key setup is already implemented in Tails.
It's very unclear what exactly this GUI would and wouldn't do.
At least your "Turn an USB stick into an USB Tails server stick", "Set
up Tor hidden services" and "Install a gobby service" iterations do
need, I guess, some kind of integrated GUI.
> Proposed Development Methods
> Since tests are good, I'll try to do Test Driven Developments, and
> on a larger scope Behavior Driven Development as much as possible.
> Doing so will provide a maintainable and easily refactorable piece
> of software.
I know you are fully aware that behavioral testing of such kind of
features (and, even better, testing at full OS scale) is far from
being trivial, and I'm concerned not to see any time scheduled, either
in the bonding period or in the GSoC coding time, to learn and setup
a suitable testing environment that would be fit for this project.
> 1st iteration: Unlocking persistence without a GUI
> The end user should be able to unlock and boot a Tails server USB
> stick without any GUI. As previously said, since I don't have any
> satisfying idea about how I am going to implement this, the how will
> be designed at this iteration..
I think this is an important feature, but not enough to be worth being
implemented first. I think it should be postponed to some later
iteration, such as after "Turn an USB stick into an USB Tails server
stick".
> 6th iteration: Install a gobby service
> This is the first Tor hidden service implementation and it will
> allow the user to run a Gobby service from the Tails server.
> This step does not involve any configuration of the service, only
> the setup; no user interactions are involved during this milestone,
> since there is no configuration involved.
Given you postponed packages installation to post-GSoC, I suggest not
to call this iteration "Install..." but rather e.g. "Setup and
start...".
> I'm planing to do a blog post about what I have done during the
> week; features implemented, problems encountered, what is still to
> be done, what are my objectives for the next week,
Are you fine with "shipping" (== tagging, at least) some kind of
working milestone every week (or once every two weeks)?
It would allow us to test your results in a known working state.
(To satisfy this goal, one generally needs to merge new features in
only once they're ready enough for others to test.)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
