Hi,
> At 32C3 we got quite inspired by the Tor presentation about onion
> services and started reviewing the plan we had on the Tails Server
> blueprint [0] with segfault.
>
> [0]: https://tails.boum.org/blueprint/server_edition/
>
> The Tails Server project has been on hold for many years, but segfault
> and anonym are interested in doing a GSoC about it this year. Yeah!
> I volunteered to help with the UX side of things.
Yay!
> Building on the simplified edition [1] I think we should aim at making
> the project as incremental as possible, getting really quickly to the
> minimal functionalities needed to get one or two templates for services
> and add more advanced administration features later in parallel with
> developing templates for more services.
>
> [1]: https://tails.boum.org/blueprint/server_edition#index7h1
Yes, this is what I planned to do :)
> Ground work
> ===========
>
> It's also worth noted that this come when:
>
> - The integration of OnionShare is moving forward [2] with some patches
> proposed to our tor-controlport-filter to support creating ephemeral
> onion services.
>
> [2]: https://labs.riseup.net/code/issues/7870#note-15
I took note of this, but as I understand it, this will only enable
_ephemeral_ onion services, not reuse a key and onion address generated
previously, right? I plan to support both, persistent and ephemeral
onion services. Currently I think I will have to bind mount the hidden
service directory and reload Tor, just like it in the mumble server script.
> - We discovered other related works towards having a more feature-full
> Tor control port filter [3].
>
> [3]: https://labs.riseup.net/code/issues/6742#note-13
Mmh, I think I should look for the Tor control port documentation and
read it. But first I have to focus on the GSoC application.
> - We know have a script to run a Mumble server from Tails [4] and are
> considering adding it to Tails [5].
>
> [4]: https://labs.riseup.net/code/issues/9993
> [5]: https://labs.riseup.net/code/issues/11241
Yes, that's great! And the current version is really nice. I already
have some scripts written on my own to start other services, but the
mumble server one definitely does some things nicer than I do - it will
be very helpful during this project. Although it's a shell script and I
will implement the server in python3.
> - We have some very rough instructions to serve HTTP requests from Tails
> [6] and segfault has been working on making this available even when no
> administration password is set in Tails Greeter [7].
>
> [6]: https://labs.riseup.net/code/issues/10970
> [7]: https://labs.riseup.net/code/issues/7879
I think this is a misunderstanding - actually my scripts need to be
executed as root and were never supposed to work without root. That
would definitely be a nice feature, but I don't think I will make this a
requirement for the GSoC project, because I think it won't be easy to
realize.
> - We wrote a statement of how Tails derivatives should be designed [8]
> which envision the need for more powerful customization mechanisms
> embedded in Tails.
>
> [8]: https://tails.boum.org/contribute/derivatives/
>
> Simplified edition reviewed
> ===========================
>
> The current blueprint insists a lot on making Tails Server a special
> mode of operation, triggered on boot, and the possibility of running on
> dedicated hardware (possibly with no X). It's also based on slightly
> outdated assumptions:
I agree, the blueprint makes a lot of assumptions - I want to work on
the "simplified edition".
> - In [9] the blueprint seems to not take into account that we already
> have the Additional Software persistence feature.
>
> [9]: https://tails.boum.org/blueprint/server_edition#index11h2
We could use the Additional Software persistence feature, but the last
time I used it, it installed the packages automatically at the end of
the boot up, increasing the time the user has to wait before he can use
the system. I guess this is still the case, right? I think installing
them only when the user actually wants to start the service provides
better UX. I prefer it this way, at least until we manage to make the
rest of the Tails server run without root privileges.
> - We now have a screen locker so a normal Tails session can be locked
> down properly and the special mode of operation is not needed for that.
Yes, that's also nice :)
>
> - We removed Vidalia in 2.2.
>
> So I propose that we don't make this special mode of operation a strict
> requirement for a first implementation and focus instead on being able
> to configure, start, and stop services from a normal Tails system, with
> persistence enabled and a GNOME session.
Agreed, that's what I planned too.
>
> The "Use cases" and "Vision" sections of the blueprint would remain the
> same (except the Alice and Bob user scenario) but the "Roadmap",
> "Timeline", and "Implementation" sections would have to be rewritten to
> make the special mode of operation an additional feature to be worked
> upon in a second phase.
>
> How does this sound?
Great!
>
> If we agree on this maybe a next step would be to rewrite the blueprint
> to come up with a realistic step-by-step plan that fits in a GSoC.
> I have no clue how to do this myself :)
I guess that will be my job :)
I will start in the next days.
Cheers!
