Re: [Tails-dev] [GSoC] Tails Server - status report 5
segfault wrote (19 Jul 2016 11:06:49 GMT) : > I created a PO to translate the strins. But I didn't know how to > integrate it in Tails, so I just put it in > `config/chroot_local-includes/usr/share/locale/de/LC_MESSAGES/` (but I > know that's not how it's done). Anyway, you can take a look at it here: > https://gitlab.com/segfault_/tails/blob/feature/5688-tails-server/config/chroot_local-includes/usr/share/locale/de/LC_MESSAGES/tails-server.po See refresh-translations and po/POTFILES.in :) ___ 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.
Re: [Tails-dev] [GSoC] Tails Server - status report 5
sajolida: > segfault: [...] >> - Write documentation > > Where can I see this? Currently I only have this documentation for the Mumble server: https://gitlab.com/segfault_/tails/blob/feature/5688-tails-server/wiki/src/doc/tails_server/mumble.mdwn >> - Make the application translatable > > I really want to review all your user-visible strings at some point but > I'll wait until I can see all of them in a PO file. I created a PO to translate the strins. But I didn't know how to integrate it in Tails, so I just put it in `config/chroot_local-includes/usr/share/locale/de/LC_MESSAGES/` (but I know that's not how it's done). Anyway, you can take a look at it here: https://gitlab.com/segfault_/tails/blob/feature/5688-tails-server/config/chroot_local-includes/usr/share/locale/de/LC_MESSAGES/tails-server.po ___ 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.
Re: [Tails-dev] [GSoC] Tails Server - status report 5
segfault: > Hi everyone, Hi! > Other things I did in the last two weeks: > > - Fix and improve the "clickable label"-widget I implemented > > - Implement the autostart feature > > - Write documentation Where can I see this? > - Make the application translatable I really want to review all your user-visible strings at some point but I'll wait until I can see all of them in a PO file. ___ 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.
Re: [Tails-dev] [GSoC] Tails Server - status report 4
sajolida: > segfault: >> [1]: >> http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/builds/ > > That's super cool! I'm downloading one now (and I hope I'll get to test > it before long) > >> * Implement three different approaches to edit the options. Discuss >> each of them on the tails-ux mailing list. Start conducting short user >> tests to get some data on which approach provides the best UX. > > Which option is built in the branch? None of the three we discussed, but simple text entries which are grayed out when the service is running. > >> Next up is (still) writing a short documentation for the upcoming user >> tests. > > Is this like writing a prototype of what the final end-user > documentation would be so that people can refer to it during the tests? Exactly. ___ 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.
Re: [Tails-dev] [GSoC] Tails Server - status report 4
segfault: > [1]: > http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/builds/ That's super cool! I'm downloading one now (and I hope I'll get to test it before long). > * Implement three different approaches to edit the options. Discuss > each of them on the tails-ux mailing list. Start conducting short user > tests to get some data on which approach provides the best UX. Which option is built in the branch? > Next up is (still) writing a short documentation for the upcoming user > tests. Is this like writing a prototype of what the final end-user documentation would be so that people can refer to it during the tests? ___ 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.
Re: [Tails-dev] [GSoC] Tails server
I strongly suggest asking on the Debian Live mailing-list how others are doing. For now, there are no automatic tests : everything is done by hand. I also strongly suggest looking at grml's setup (that uses kantan). Pointers and resources there: https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 This is why I am currently playing around with lettuce[2], a nice Python-powered BDD tool. Great. Please: * share your scenarios early (allows better communication, forces you to start small and to stay practical :) You can find the scenario for my first iteration here : http://git.immerda.ch/?p=jvoisin/tails.git;a=summary (more to follow) * file a RFP bug as soon as you're sure you want to use it -- I want your test suite to integrate nicely with our infrastructure, and that means using software that is in Debian as much as possible. For now, I'm being stuck : I have scenarios, but I have no clear ideas about how they can be run, because most of them are boot-related. I was planing to use qemu, but it doesn't seems to be able to boot from an usb stick. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev -- -- Julien Voisin | pgp key : C48815F2 http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x9768FD3CC48815F2 | dustri.org ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] Tails server
Hi, jvoisin wrote (12 Jun 2012 11:29:42 GMT) : I strongly suggest asking on the Debian Live mailing-list how others are doing. For now, there are no automatic tests : everything is done by hand. Well, it's sad there was no positive answer, but FWIW, this does not really indicate that all Debian Live downstreams do things by hand: e.g. grml folks did not answer, while they do run automated tests. I also strongly suggest looking at grml's setup (that uses kantan). Pointers and resources there: https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 Did you do so, and if you did, what was the outcome? For now, I'm being stuck : I have scenarios, but I have no clear ideas about how they can be run, because most of them are boot-related. I have a hard time believing neither the grml tools, nor any of the ones listed on our automated build and test resources [0], can be at least used as a basis. Perhaps they are too complex and/or lacking needed functionality, but please beware of the NIH syndrome :) [0] https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 And perhaps, eventually, the autotest framework won't look that overkill. Who knows. I was planing to use qemu, but it doesn't seems to be able to boot from an usb stick. KVM (qemu-kvm package) from testing/sid boots pretty well from a USB 2.0 device passed through the host to the guest. I'm unsure about regular qemu. I'm using this in libvirt/virt-manager. I hope this un-stucks you a bit :) Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] Tails server
Hi, jvoisin wrote (04 Jun 2012 11:43:12 GMT) : So far, I managed to build Tails in a virtual machine, Congrats! About the testing environment now: It seems like liveCD testing is not something that interest people very much. The autotesting repo[3] of debian-live is a 404, and even if it wasn't, the documentation is lacking. I'm not sure what it's worth, but I found it: http://live.debian.net/gitweb?p=old/autotesting.git;a=summary The mainstream way for doing system-wide/vm/liveCD tests is autotest[4], but it seems completely overkill to me. I've had a look at it, and for sure it is a bit complex, has many features, and some aspects of it may seem useless for us on the short term, but I absolutely don't see it as completely overkill. It does a complex job. I strongly suggest asking on the Debian Live mailing-list how others are doing. I also strongly suggest looking at grml's setup (that uses kantan). Pointers and resources there: https://tails.boum.org/todo/automated_builds_and_tests/#index8h2 This is why I am currently playing around with lettuce[2], a nice Python-powered BDD tool. Great. Please: * share your scenarios early (allows better communication, forces you to start small and to stay practical :) * file a RFP bug as soon as you're sure you want to use it -- I want your test suite to integrate nicely with our infrastructure, and that means using software that is in Debian as much as possible. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot
04/13/2012 11:43 PM, intrigeri: jvoisin wrote (13 Apr 2012 20:26:54 GMT) : Dealing with multiples tails-server on the same LAN: This is not a problem, since the hostname is set during the setup; it's up to the user to take care to not name multiples servers with the same name. All Tails currently ship with a common hostname. So, in case it's leaked, they're not distinguishible from the other. Moving away from this has consequences that should not be considered lightly. I'd really prefer to avoid doing it at all, if possible. If we use avahi we can let the user set the service name used for DNS-SD. See the avahi.service(5) man page. (Disclaimer: I have never used avahi so don't take my word for any of this.) A given tails-server already has (at least) one identifier: it's .onion hidden service name. Maybe we could keep the current (amnesia) hostname even for tails-server, but configure avahi to announce the .onion name on the LAN (replacing .onion with .local, I guess)? Is it possible? How does this sound? Announcing the .onion address on the LAN would effectively take out the hidden from Tor hidden service since we consider the LAN as being untrusted in our threat model (e.g. eavesdropping ISP-provided routers). Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot
Hi, anonym wrote (12 Apr 2012 13:52:00 GMT) : tails-server is expected to run on a LAN with a DHCP server (needs to be added to the specs, btw), so I don't think the user can ensure this IP is left free for this specific system? Custom static leases are often not an option. Actually, most people I know prefer to use static IP configurations for all servers on their LAN, and some people I know don't use DHCP at all. Those people use SSH, know about static DHCP leases, and setup port forwarding. I don't think they are our target userbase for Tails server. So please let's take a step back from what the tiny population of people who run a server at home are used to do. They're simply not relevant for Tails server. So let me reiterate, hopefully more clearly, what I meant with I don't think the user can ensure this IP is left free for this specific system? Most home modem/routers run a DHCP server on the LAN. Most home users use this DHCP server without knowing what DHCP is, without being aware their home router is a computer that runs DHCP server software, let alone it can (sometimes) be configured. In this context, if you want to run a server with a static IP, you have to ensure this IP is left free for this specific system, that is to somehow explain the DHCP server it should leave that IP apart so that it does not get assigned to another box, or to setup a static DHCP lease. I think Tails server users should absolutely *not* need to do this. Or did I miss an easy way to solve this static addressing problem when a DHCP server is running the place? Given this, I don't see how the static IP way would be a practical solution. Did I miss anything? The only drawback I can see with allowing this is that the static IP configuration would have to be unencrypted and stored separately from the Tails server config some how. Luckily it can easily be achieved specifying it on the kernel cmdline, and having the The Tails server configuration tool modifying the syslinux menu file accordingly. If none is given the default should of course be DHCP. I think this is already supported by live-boot / live-config. I agree we want to support this case too (seriously lower priority IMHO, though). Something slightly unrelated I just realized is that Tails server must have unencrypted persistence for being able to store certificates both in the dropbear and web server approaches for remotely unlocking the encrypted Tails server configuration. Hmm. Yeah, the USB stick must be able to produce some information that allows it to authenticate itself somehow. Do we actually have to run this in initramfs? Why not early init? Oh, you're absolutely right. Sorry for spreading confusion. Using https would of course be nice, but since this implies using self-signed certs (right ?), it might scare users. If you decide to go the HTTP way: I agree self-signed certs, unless well integrated into the client's persistent configuration, are a no-go. Such integration is a must. Perhaps a Tails server persistence preset (stored at ~/.tails-servers) could host these? Any certificates found there would be added to iceweasel on as soon as Tails has opened the persistent volume and found this preset. Yes. This was exactly what I expected Julien to reply. This is why I think that the best solution would be to use avahi, but this may require some digging into tails firewall. Maybe. This is the bigger question to me, i.e. how to locate the (most likely DHCP-using) Tails server. Therefore avahi/zeroconf, or similar, seems absolutely necessary. Or am I missing something? My maybe was about the firewall holes. This holes do not need to be permanent: [...] OTOH, the web server approach allows a ridiculously simple client-side GUI in Tails that starts/stops avahi, and scans and lists Tails servers (and yes, there can be many, so it should be possible to distinguish between them some how). When clicked, iceweasel simply opens the selected server. This should even be doable in fairly small shell script using zenity :). I think it still is a pretty nice advantage to be able to unlock the Tails server from any avahi/zeroconf-aware OS compared to just from another Tails instance. Sure. This was exactly what I expected Julien to reply. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot
04/13/2012 10:55 AM, intrigeri: Hi, anonym wrote (12 Apr 2012 13:52:00 GMT) : tails-server is expected to run on a LAN with a DHCP server (needs to be added to the specs, btw), so I don't think the user can ensure this IP is left free for this specific system? Custom static leases are often not an option. Actually, most people I know prefer to use static IP configurations for all servers on their LAN, and some people I know don't use DHCP at all. Those people use SSH, know about static DHCP leases, and setup port forwarding. I don't think they are our target userbase for Tails server. We shouldn't exclude them either. Or did I miss an easy way to solve this static addressing problem when a DHCP server is running the place? That's up to the user. Note that I only want static IP configuration to be supported, not the default. Given this, I don't see how the static IP way would be a practical solution. Did I miss anything? The only drawback I can see with allowing this is that the static IP configuration would have to be unencrypted and stored separately from the Tails server config some how. Luckily it can easily be achieved specifying it on the kernel cmdline, and having the The Tails server configuration tool modifying the syslinux menu file accordingly. If none is given the default should of course be DHCP. I think this is already supported by live-boot / live-config. Ah! Indeed, the `ip` boot parameter does the trick. Thanks live-boot! I agree we want to support this case too (seriously lower priority IMHO, though). I could buy the argument that people who uses static IP configurations likely don't need a GUI tool to set it up for them. We could just mention the `ip` boot parameter in the docs and suggest that they can manually edit the syslinux menu file to get it there persistently. Using https would of course be nice, but since this implies using self-signed certs (right ?), it might scare users. If you decide to go the HTTP way: I agree self-signed certs, unless well integrated into the client's persistent configuration, are a no-go. Such integration is a must. Perhaps a Tails server persistence preset (stored at ~/.tails-servers) could host these? Any certificates found there would be added to iceweasel on as soon as Tails has opened the persistent volume and found this preset. Yes. This was exactly what I expected Julien to reply. :/ This holes do not need to be permanent: [...] OTOH, the web server approach allows a ridiculously simple client-side GUI in Tails that starts/stops avahi, and scans and lists Tails servers (and yes, there can be many, so it should be possible to distinguish between them some how). When clicked, iceweasel simply opens the selected server. This should even be doable in fairly small shell script using zenity :). I think it still is a pretty nice advantage to be able to unlock the Tails server from any avahi/zeroconf-aware OS compared to just from another Tails instance. Sure. This was exactly what I expected Julien to reply. :/ It seems I'm too enthusiastic about solving problems rather than guiding jvoisin towards the solution. I'm sorry for this. I'll try to shut up more. Cheers! signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot
Hello, Since anonym answered a large part of tails-server's passphrase-input-related interrogation, I'll go with some of the remaining ones: Dealing with multiples tails-server on the same LAN: This is not a problem, since the hostname is set during the setup; it's up to the user to take care to not name multiples servers with the same name. What if the screen is broken but the keyboard is still available ? We must find a way to tell to the user when he should enter his passphrase, and the result of the operation (good/bad passphrase). A good solution could be to communicate thought the keyboard's capslock LED. For example: - Continuous blink : please enter your passphrase - Two quick-blink : good passphrase - No more blink until the user can input his passphrase again, in case of bad passphrase. Since not every keyboards have a capslock LED, we could use the system speaker instead; but since this involve waking up the whole house when the server is booted up, I prefer the LED solution. As previously said, in order to authenticate the server, the user must carry a private key (dropbear approach), or a certificate fingerprint (webpage approach). But the server must also have an unencrypted partition, to carry public keys (dropbear), and certs (webpage). Since the dropbear approach will require user authentication, in order to provide a password-less shell access, the webpage one does not : tails-server does not care about who you are, the only thing that matter is that you have the right passphrase. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] [tails-server] Ideas and challenges about asking the user's passphrase on boot
04/12/2012 11:52 AM, intrigeri: Hi Julien, jvoisin wrote (11 Apr 2012 23:38:01 GMT) : I have some questions/ideas about tail-server, especially about the early boot process; and I'd like to share them to get advices/options. Glad to read this. I think that a good way to get the passphrase would be to setup a simple webpage, available on the LAN (for now, I only consider that the machine has one interface : the LAN). See bellow an alternative idea. But this raise (at least) two majors concerns: 1. Disclose the server's presence on the network In order to be able to type his passphrase on the webpage, the user must know where is his tails-server on his network. The first (and easiest) solution would be to hardcode tails-server's ip during the setup of the persistence USB key; but this solution require to know on which network will tails-server run. tails-server is expected to run on a LAN with a DHCP server (needs to be added to the specs, btw), so I don't think the user can ensure this IP is left free for this specific system? Custom static leases are often not an option. Actually, most people I know prefer to use static IP configurations for all servers on their LAN, and some people I know don't use DHCP at all. Given this, I don't see how the static IP way would be a practical solution. Did I miss anything? The only drawback I can see with allowing this is that the static IP configuration would have to be unencrypted and stored separately from the Tails server config some how. Luckily it can easily be achieved specifying it on the kernel cmdline, and having the The Tails server configuration tool modifying the syslinux menu file accordingly. If none is given the default should of course be DHCP. Something slightly unrelated I just realized is that Tails server must have unencrypted persistence for being able to store certificates both in the dropbear and web server approaches for remotely unlocking the encrypted Tails server configuration. Hmm. 2. Run a webpage Setup a php/apache seems a little bit overkill; Absolutely. I think that some python (or perl) magic will be sufficient. A simple CGI would probably do, but a CGI is useless without a (lightweight -- remember we're in initramfs) Do we actually have to run this in initramfs? Why not early init? Using https would of course be nice, but since this implies using self-signed certs (right ?), it might scare users. If you decide to go the HTTP way: I agree self-signed certs, unless well integrated into the client's persistent configuration, are a no-go. Such integration is a must. Perhaps a Tails server persistence preset (stored at ~/.tails-servers) could host these? Any certificates found there would be added to iceweasel on as soon as Tails has opened the persistent volume and found this preset. An issue with both this approach and the corresponding step in intrigeri's dropbear approach (i.e. putting the fingerprint in ~/.ssh/known_hosts) is that the user must have chosen these persistence presets *before* installing the Tails server. That is unless we are willing to start adding *and* *activating* presets while Tails is running. This is why I think that the best solution would be to use avahi, but this may require some digging into tails firewall. Maybe. This is the bigger question to me, i.e. how to locate the (most likely DHCP-using) Tails server. Therefore avahi/zeroconf, or similar, seems absolutely necessary. Or am I missing something? This holes do not need to be permanent: * On server side, that could be only while dropbear is running. The same applies for a web server hosting the unlock page. * On the client side, only while the network is probed for servers. This probably can be made safe enough, with enough care and thought: one should seriously study what exact additional attack surface it adds, for what attacker, and when. BTW, this calls for a client-side GUI rather than a web interface. We don't want the web browser to start / stop avahi. I suppose this may be the bane of the web server + HTTPS approach. OTOH, the web server approach allows a ridiculously simple client-side GUI in Tails that starts/stops avahi, and scans and lists Tails servers (and yes, there can be many, so it should be possible to distinguish between them some how). When clicked, iceweasel simply opens the selected server. This should even be doable in fairly small shell script using zenity :). I think it still is a pretty nice advantage to be able to unlock the Tails server from any avahi/zeroconf-aware OS compared to just from another Tails instance. (Note that I'm personally content with this dropbear + clientside GUI approach. I'm just being the devil's advocate here so that when we decide not to do something, we do so for the right reasons.) Cheers! signature.asc Description: OpenPGP digital signature ___
Re: [Tails-dev] [GSoC] Tails server
Hi Julien, intrigeri wrote (05 Apr 2012 21:54:06 GMT) : the deadline is now *soon*. I have enabled proposal modifications on Melange, so we have about one week to discuss the remaining concerns we have, and you have about one bonus week improve your application accordingly. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] [GSoC] Tails server
Hi, the deadline is now *soon*. See bellow some new comments, and some old comments reasserted. jvoisin wrote (04 Apr 2012 11:14:05 GMT) : Please found attached the current version of my proposal to review. The preference USB stick term is not defined, and does not match what we've been using to describe the Tails persistence storage. Either use commonly agreed terms, or explain how and why what you mean is different. Also, you use the configuration USB stick wording somewhere else. 5.1 Persistence I guess you plan to use the persistence feature that will be shipped in Tails 0.11, but this is left for the reader to guess. I think it should be made explicit. 5.3 Boot process I think some steps are missing: * when is the persistent storage passphrase asked to the user? * when is the persistent storage unlocked, and persistence feature activated? (FYI this is done, in Tails 0.11, at tails-greeter time, by unlocking the LUKS volume and running the live-persist program). 5.5 Services * I think etherpad is the name of a specific piece of software, and not (yet) of a feature. The collaborative text editing wording would look clearer to me, when you're talking of this feature, implemented by another piece of software 5.8 GUI * Setup of the persistence USB stick Tails 0.11 will ship a GUI that already does exactly this part. 7. Timeline 3nd iteration (sic) - Remote administration How is the user supposed to authenticate as root to the SSH server? 6th iteration Install a gobby service 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. Is protecting the Gobby service with a password postponed to step #7? 7th iteration Basic configuration management The user should be able to edit the configuration of the Gobby service during the creation of the Tails server USB stick. What configuration are you thinking of? Random comments: * In Debian, a package manager is something like APT. I think you rather intend to ask package *maintainers* to add debconf options. * The Wheezy release is *not* planned for June. The freeze is. * My remarks about sobby vs. infinoted-0.5, were not taken into account at all, so this part of your text still feels seriously wrong. See my email sent on Fri, 30 Mar 2012. * I see no clear explanation of the actual configuration management problem you're trying to solve. I asked this explanation on Sun, 25 Mar 2012. * s/debian/Debian/ * s/Ssh/SSH/, again. * s/packet/package/, again. * s/will me/will be/ * s/tails/Tails/ * s/starup/startup/ * more generally, a spell check pass would be welcome Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
