[Tails-dev] [review] fix link
Hi, Please review (and maybe merge): https://gitorious.org/flapflap/tailsxlat.git branch wiki-fix-fullstop Commits: 36001f1 fix '.' in URL In a link on the doc/about/warning.mdwn page, there was a double '.' at the end of a sentence. It's not part of the title of the referenced webpage and (I think :-) it looks unaesthetic.. I fixed it in the mdwn version /and de-fr-pt translations/. ~flapflap signature.asc Description: OpenPGP digital signature ___ 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] [review] Run a HTTP server as an Hidden Service insideTails.
matsa: Tails can be used to run a HTTP server, nginx, as an Hidden Service. The documentation is available here: http://repo.or.cz/w/tails/matsa.git/blob/refs/heads/7879-http-server-with-nginx:/wiki/src/doc/advanced_topics/http_server_with_nginx.mdwn And the Redmine ticket is there: https://labs.riseup.net/code/issues/7879#change-31403 Feedback is welcome! Thanks for working on this. I tried to improve your instructions and based my work on lighttpd. I managed to reduce the lines of code from 43 down to 12. The tricks are: - Use the default configuration of lighttpd. - Add lighttpd to live-additional-software.conf. - Store the hidden service folder in persistence. - Store the files in the Persistent folder. What do you think? To create the hidden service echo lighttpd /live/persistence/TailsData_unlocked/live-additional-software.conf echo /var/www source=Persistent/www /live/persistence/TailsData_unlocked/persistence.conf echo /var/lib/tor/lighttpd source=tor/lighttpd /live/persistence/TailsData_unlocked/persistence.conf Reboot and wait for the additional software notification. chown debian-tor:debian-tor /var/lib/tor/lighttpd chown amnesia:amnesia /home/amnesia/Persistent/www chmod 755 /home/amnesia/Persistent/www echo HiddenServiceDir /var/lib/tor/lighttpd/ /etc/tor/torrc echo HiddenServicePort 80 /etc/tor/torrc service tor restart cat /var/lib/tor/lighttpd/hostname To reboot = echo HiddenServiceDir /var/lib/tor/lighttpd/ /etc/tor/torrc echo HiddenServicePort 80 /etc/tor/torrc service tor restart ___ 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] Git branches to delete: review needed
Hi, intrigeri intrig...@boum.org wrote: Please have a look and shout if there's something in there that we should keep. Looks good to me. Also, if you're Alan, anonym, bertagaz or sajolida, look for your name on that blueprint: there are a few branches I need your opinion about = please move them to the appropriate section. * feature/edit-additional-software-conffile: this branch adds a subcommand to tails-additionnal software to ease creation/edition of its configuration. I don't remember why it never got merged. * feature/fix_additional_software_escalation: this branch is not useful anymore as it addresses a problem that has been solve another way. * feature/update_whisperback_help: I don't understand why this branch got lost, but we should really merge it, so don't delete it! 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.
[Tails-dev] review and merge
Ticket:https://labs.riseup.net/code/issues/7417 Mention the ISO file size on the download page Branch:web/7417-add-iso-size into devel Milestone: 1.3 ___ 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.
[Tails-dev] Git history rewrite
Hi folks, I want to make you all aware that we will be rewriting the git history of tails.git, our main git repository. To make it easy for everybody and have less pain for us or for yourself in the future. I would like to ask you to push any local branches you might have laying around, even if the work isn't finished, to the git repo. Please do not postpone! :-) All the best, Jurre ___ 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.
[Tails-dev] Git branches to delete: review needed
Hi, ETA: Tuesday, noon CET. before rewriting the Git history, we'll first delete a bunch of branches. Not only the already merged ones, as mentioned by Jurre earlier today on this list; but also a lot of now-irrelevant branches. I've compiled a list of branches I think we can delete, in the Can be deleted section of this blueprint: https://tails.boum.org/blueprint/rewrite_Git_history/ Please have a look and shout if there's something in there that we should keep. Also, if you're Alan, anonym, bertagaz or sajolida, look for your name on that blueprint: there are a few branches I need your opinion about = please move them to the appropriate section. Thanks in advance! Cheers, -- intrigeri ___ 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] Automated builds specification
Alan wrote (21 Feb 2015 13:36:41 GMT) : Most of us (including me) do the same as Alan, but IMO that's almost irrelevant to the topic at hand. This same scenario reads: And I need to know if my branch build is broken by something else possibly weeks after my last commit (by e.g Debian changes, changes in branch B, ...) ^^^ ... and we cannot possibly get this without locally merging the topic branch F into B before building. The important point here may be the *locally* word. This merge would only be done in Jenkins own temporary Git checkout, and wouldn't affect how we're handling our branches' Git history. But I agree this is not the best way to go, so if Alan doesn't come up with a block on this, I agree to add the clarification. OK. But apparently, either I misunderstood why Alan had trouble with this idea, or Alan has misunderstood the idea, so IMO it would be good to have his opinion now that I've clarified what I think we should do, and why. Alan? I do not see any issue with this local merge by our autobuilder. Looks to me like the right thing to do. Thanks for the clarification! bertagaz: I think it can now be clarified accordingly on the blueprint :) Cheers, -- intrigeri ___ 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] Git history rewrite
Hi, some additional timing info: Jurre van Bergen wrote (21 Feb 2015 11:08:44 GMT) : I want to make you all aware that we will be rewriting the git history of tails.git, our main git repository. ... and this task is meant to be completed by the end of the month. To make it easy for everybody and have less pain for us or for yourself in the future. I would like to ask you to push any local branches you might have laying around, even if the work isn't finished, to the git repo. ... by Monday at noon CET. Thanks! Cheers, -- intrigeri ___ 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.
[Tails-dev] Blueprint: delete obsolete Git branches (review)
Hoi, I have worked on a blueprint (delete obsolete Git branches)[1] and would like to ask you to review it. Does the proposed workflow makes sense? Did I miss anything? Would you like to see anything changed and if so, why? [1] https://tails.boum.org/blueprint/delete_obsolete_Git_branches Thanks! All the best, Jurre ___ 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] Automated builds specification
Hi, intrigeri intrig...@boum.org wrote: bertagaz wrote (16 Feb 2015 14:32:57 GMT) : On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote: I have a few concerns, though: * Scenario 2 : developer doesn't make it clear if branch T is build *after being locally merged into branch B*, or not. Given that's what we're really interested in, and given Scenario 1 : reviewer is clearer (answer is: yes), I guess the answer is yes here too, but this should be clarified. IIRC that was something Alan had troubles with, as not being the way she usually work on a feature branch, which I think was more close to Work work work on the branch, and then when the feature is ready, merge the base branch in it. So she usually do not merge the base branch very often. Most of us (including me) do the same as Alan, but IMO that's almost irrelevant to the topic at hand. This same scenario reads: And I need to know if my branch build is broken by something else possibly weeks after my last commit (by e.g Debian changes, changes in branch B, ...) ^^^ ... and we cannot possibly get this without locally merging the topic branch F into B before building. The important point here may be the *locally* word. This merge would only be done in Jenkins own temporary Git checkout, and wouldn't affect how we're handling our branches' Git history. But I agree this is not the best way to go, so if Alan doesn't come up with a block on this, I agree to add the clarification. OK. But apparently, either I misunderstood why Alan had trouble with this idea, or Alan has misunderstood the idea, so IMO it would be good to have his opinion now that I've clarified what I think we should do, and why. Alan? I do not see any issue with this local merge by our autobuilder. Looks to me like the right thing to do. 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.
Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Alan: On Thu, 19 Feb 2015 14:23:03 + sajolida sajol...@pimienta.org wrote: intrigeri: sajolida wrote (18 Feb 2015 11:32:17 GMT) : intrigeri: Alan wrote (12 Feb 2015 15:32:15 GMT) : - Ability to close a circuit manually. [...] = seems like we can address this corner case in a good-enough way without compromising security nor spending large amounts of energy on this topic. Fine with me. Still, we would need to have arm documented in the first place. And since I propose it to go in Advanced topics anyway we can explain the workaround there for now and create the upstream ticket that you mentioned as well. +1 [About the green onion] There's no green onion in the quoted emails above that. So I understand that you're agreeing on having a green onion displayed somewhere on the desktop once Tor is started. If not please clarify. And I'm fine with mimicking this behavior for a start if that's easier to implement (no regression), but I think this is buggy (the onion shouldn't be green if Tor is not in a working state anymore). I want to replace Vidalia to get rid of its bugs not to reimplement them :) but would it be conceivable to have Tor Monitor appear as green onion on the desktop as Vidalia does until now? I don't think it's the way to go: - I'd like Tor Monitor to stay a generic application, with a clear focus on being a monitor for Tor and showing whatever icon on the desktop doesn't look like the same task for me. I beg to disagree. To me monitoring Tor also means being able to have some clue at any time about whether it's been started or not, from the desktop. So the green onion is part of monitoring Tor for me, it's status icon. At least as far as we agree on keeping that green onion (see the beginning of that mail). - System Tray Icons were deprecated in Gtk since 3.14. A proper implementation of this green onion for GNOME 3 desktop would be a (very simple) Shell extension, to which we (the NetworkManager hook) should send a DBus signal (or the opposite). That might be a tiny funny project. If we agree on keeping the green onion then I don't care whether we have one, two, or n pieces of software. I tend to believe that having one is simpler than having two (when possible) but I don't know GNOME internals as much as you do. If the green onion needs to be a shell extension, then maybe Tor Monitor should be part of that same shell extension. This shell extension would appear as an icon on the desktop and have an option to open a window with the details of the circuits. Like our OpenPGP Applet does: you click on it, choose Encrypt Clipboard with Public Keys, and it opens a window with a list of keys. Yes, and if I understood correctly Tor Monitor currently needs Tails Jessie. So an obvious roadmap would be to have a working replacement of Vidalia with Tor Monitor (without regressions) in Tails Jessie. Does that sound realistic? Then only we can work on making it better (eg. smarter onion status icon, progress bar while starting Tor, etc.). And if Tor Monitor is always running in the background, then maybe it could also provide information while Tor is starting and be the right tool to solve #7437 in the future? That's what I had hidden in the back of my head when asking this question initially :) I'm not opposed to exposing a DBus interface in a future version of TorMonitor to provide the green onion or other applications more information that our hooks could. But I'm not sure it is the right place to do it yet. ___ 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.
