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! _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.