[Tails-dev] Made New Identity work again, please review
+TOR_CONTROL_PASSWD='passwd' Why do we set this? Iceweasel (as amnesia) does not have access to the authentication cookie, and shouldn't. If Torbutton cannot read the authentication cookie, it refuses to talk to the control port, even when substituted with this filter. So I need to tell it what the cookie is using TOR_CONTROL_PASSWD, and it will now talk to the filter trying to authenticate with this value instead. The filter accepts all authentication regardless of value, as noted in the code. Ah, I see. Could you please add a code comment at the place where `TOR_CONTROL_PASSWD` is set, explaining this non-obvious (at least to me :)) assignment? Done, same branch (winterfairy:bugfix/torbutton-new-identity). ___ 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] Made New Identity work again, please review
anonym wrote: 11/02/14 19:14, winterfairy at riseup.net wrote: I believe I have fixed the regression described in ticket #6383. When access to Tor's control port was restricted (to prevent GETINFO address), Torbutton could no longer do New Identity. I have created a filtering proxy for the control port, that only allows SIGNAL NEWNYM. This is enough to make New Identity work again as expected. Branch winterfairy:bugfix/torbutton-new-identity in my Tails repo (based on devel). Thanks for you contribution! Please review and test it, and merge it is it looks fine. If you believe something could be improved, or should be done differently, please say. My test looked good. When it comes to reviewing I don't have much to add as intrigeri caught most blockers: +TOR_CONTROL_PASSWD='passwd' Why do we set this? Iceweasel (as amnesia) does not have access to the authentication cookie, and shouldn't. If Torbutton cannot read the authentication cookie, it refuses to talk to the control port, even when substituted with this filter. So I need to tell it what the cookie is using TOR_CONTROL_PASSWD, and it will now talk to the filter trying to authenticate with this value instead. The filter accepts all authentication regardless of value, as noted in the code. + # Read in a newline terminated line (max 128 chars) + line = readh.readline(128) Why do we read 128 characters specifically (same thing done for all other socket reads)? Tor's control language always terminate responses with CRLF so why can't we use `readline()` without argument, which reads until a LF? I suppose that'll leave a trailing CR, but that could be dropped if necessary, which I don't think we need to care about because of how we verify responses with `startswith`. By limiting line length, we gain some protection against DoS attacks on the filter. The attacker cannot trigger an OOM by sending a 10 GB long row, for example, thereas that maybe would be possible if reading until LF. I feel slightly more comfortable knowing you cannot OOM/crash the application, even if there is other ways to prevent the user from reaching the control port filter (all this assuming the attacker is running software as amnesia). While I'm pretty sure this will be ok in the subset of the control language we deal with (*currently*), I'd at least want to hear how you thought about this with a code comment. While you're at it, it'd be great if you made the reads use a nicely named constant (and put the comment where it's defined) instead of magic 128:s everywhere. Done, same branch. After that's fixed I'm ready to merge this. As a side note, I suppose it'd be nice to use stem [1] to greatly simplify the script and in particular avoid the low-level socket stuff but it's not packaged in Debian. :/ [1] https://stem.torproject.org/ I am not familiar with Stem, so I cannot tell. But I think it might only help with the talking to a control port stuff, not simulating our own control port stuff. ___ 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] Made New Identity work again, please review
intrigeri wrote: winterfairy at riseup.net wrote (20 Feb 2014 11:52:17 GMT) : 3. It might be overkill, and surely adds some code, but I would pass the port to listen on, control port socket path and authentication cookie path as command-line arguments (preferably named, not positional). Just to make it easier for others to reuse this piece of code, and increase collaboration between similar projects. A quick research showed up that this can probably be done with only a few lines of code if using the modules optparse or argparse. Python 2.6 (which Tails uses) only has optparse. In python 2.7 optparse is deprecated and replaced by argparse. This would mean writing one version for squeeze and one for wheezy. I don't think it is worth it currently. Fair enough. Care to file a ticket, blocked by #6015, so that this is not forgotten at post-1.1 time? I guess I should wait until my branch is actually accepted/merged into devel? If you also mark the new ticket as blocked by the new identity one, I see little use in waiting :) Ticket filed. https://labs.riseup.net/code/issues/6742 ___ 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] Adding BitMessage and Bitcoin-QT to Tails
intrigeri wrote: winterfairy at riseup.net wrote (14 Feb 2014 15:05:56 GMT) : Electrum sounds interesting, if we want a Bitcoin client in Tails. At least, anyone who has been doing some Tails user support knows for sure there is some demand and use cases. Electrum is not part of Debian stable, but it is in Debian testing/sid. It would be good to know if it can be backported to Wheezy. Vasudev, would you be interested in having a look? (No, I'm *not* writing this with my AM hat ;) Added ticket about inclusion of Electrum in Tails: https://labs.riseup.net/code/issues/6739 ___ 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] Made New Identity work again, please review
intrigeri wrote: Hi, (Note: it would be great not to break threading: anyone reading the old thread, but not this one, will miss your reply etc. IIRC you read the list via the archives, so I understand it's a bit of a pain, but hopefully your MUA allows you to insert arbitrary References and In-Reply-To headers.) Don't think so. Sorry. 3. It might be overkill, and surely adds some code, but I would pass the port to listen on, control port socket path and authentication cookie path as command-line arguments (preferably named, not positional). Just to make it easier for others to reuse this piece of code, and increase collaboration between similar projects. A quick research showed up that this can probably be done with only a few lines of code if using the modules optparse or argparse. Python 2.6 (which Tails uses) only has optparse. In python 2.7 optparse is deprecated and replaced by argparse. This would mean writing one version for squeeze and one for wheezy. I don't think it is worth it currently. Fair enough. Care to file a ticket, blocked by #6015, so that this is not forgotten at post-1.1 time? I guess I should wait until my branch is actually accepted/merged into devel? ___ 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] Adding BitMessage and Bitcoin-QT to Tails
Bitcoin-QT is also useful For a live-cd I would prefer the Bitcoin client Electrum because you need only a passphrase to restore your wallet after reboot and you don't have to download the full blockchain. See: https://electrum.org/index.html If I may chime in I'd say that I installed it on tails two versions ago and it's been working fine since then. I can give you the exact commands I use as well as the hidden service it connects to. Electrum sounds interesting, if we want a Bitcoin client in Tails. Bug tracker is down currently, so I cannot verify what our opinion is and what earlier efforts have been made. If I understand it correctly, having a Bitcoin client is preferred to using e.g. blockchain.info, as the remote server cannot learn your encryption keys. Please tell us any information (e.g. commands) we need to make it easier for us to evaluate this software in Tails. (I'll try to remember to add that to the right tickets when bug tracker is back up again.) ___ 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] Made New Identity work again, please review
intrigeri wrote: winterfairy wrote: I believe I have fixed the regression described in ticket #6383. When access to Tor's control port was restricted (to prevent GETINFO address), Torbutton could no longer do New Identity. I have created a filtering proxy for the control port, that only allows SIGNAL NEWNYM. This is enough to make New Identity work again as expected. Congrats! This usability regression was one of the top mentionned ones in my experience when doing user support in the last few months. I won't be doing the entire review'n'merge process, but I had a quick look, and here are a few quick notes: 1. I'm not entirely convinced by the idea of running tor-controlport-filter as the vidalia user. Granted, it's the shortest path, but it feels weird, and having a bit more privilege separation would be good. Fixed. Same branch. 2. The use of string.find(expected text) seems a bit fragile. Couldn't this matching be done in a bit stricter way? I am not sure what you mean by stricter. I changed it to startswith() anyway, which is equivalent to what I did, but clearer. find() reports position of first occurence (-1 on error). I was testing that the position was == 0. 3. It might be overkill, and surely adds some code, but I would pass the port to listen on, control port socket path and authentication cookie path as command-line arguments (preferably named, not positional). Just to make it easier for others to reuse this piece of code, and increase collaboration between similar projects. A quick research showed up that this can probably be done with only a few lines of code if using the modules optparse or argparse. Python 2.6 (which Tails uses) only has optparse. In python 2.7 optparse is deprecated and replaced by argparse. This would mean writing one version for squeeze and one for wheezy. I don't think it is worth it currently. Other than this, I was (once again!) impressed by the quality of this submission. I've merged it into our experimental branch, and pushed to our master repository + to our Jenkins auto-builder. Thanks. (I did not use Whonix existing implementation, because I felt very uneasy about running a potentially security critical application as a shell script. Fully agreed. I suggest you point the Whonix developers to your own implementation, once it's merged. Ok. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Make it possible to manually start IBus on all locales, please review
intrigeri wrote: winterfairy at riseup.net wrote (08 Feb 2014 16:30:49 GMT) : AFAIK, there is no ticket tracking this regression. The original issue was a subitem in #5624. I suggest you file a ticket, with milestone = 0.23, assigned to the current RM (anonym), so that this isn't lost among the immense pile of email backlog I expect he is currently dealing with. Thanks! :) Done as ticket #6656. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Made New Identity work again, please review
I believe I have fixed the regression described in ticket #6383. When access to Tor's control port was restricted (to prevent GETINFO address), Torbutton could no longer do New Identity. I have created a filtering proxy for the control port, that only allows SIGNAL NEWNYM. This is enough to make New Identity work again as expected. Branch winterfairy:bugfix/torbutton-new-identity in my Tails repo (based on devel). The design documentation is also updated, and the issue removed from known issues. Well tested during development, both in normal operation and failure conditions (real and faked). Also tested by patching a Tails 0.22.1 installation, and ensuring it works live (circuits gets replaced as shown in Vidalia's network map). Please review and test it, and merge it is it looks fine. If you believe something could be improved, or should be done differently, please say. (I did not use Whonix existing implementation, because I felt very uneasy about running a potentially security critical application as a shell script. Also, it required dependencies not currently in Tails, it seems, and I have not the knowledge to review shell scripts from a security point of view.) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Make all .desktop-files translatable in Transifex
intrigeri wrote: winterfairy at riseup.net wrote (08 Dec 2013 11:54:32 GMT) : I just filed ticket #6470, https://labs.riseup.net/code/issues/6470: [...] To sum up my thoughts: * liveusb-creator-launcher.desktop: yes * tails-upgrader.desktop: can be integrated as-is * WhisperBack: no, IMHO it should be done in its own repo * Perl programs: I'll have a look later How about you create sub-tasks of #6470 for each of those, and start with the easiest ones (installer and upgrader)? During the December 2013 meeting the following was decided: None of the desktop file should be moved to any other repository. Everyone want them in their respective repository long-term, even if we where to move them to the Tails main repo to make it easy for us on the short-term. Also, moving them so they are separate from the actual application will probably cause problem with keeping them in sync, among other things. All of the desktop files should be made translatable using intltool. How to make use of intltool in each affected repository differ due to different build systems. Subticket for #6470 is created accordingly for each project. intrigeri will look into the Perl ones (persistence-setup, any more that I missed?). We also discussed whether it was an issue that the translated names wasn't the same as the untranslated English names in the documentation, but decided this is not an issue. If one can read the English documentation, one can probably map the names to the translated ones too. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, take two, please review
intrigeri wrote: winterfairy at riseup.net wrote (07 Dec 2013 17:02:43 GMT) : Done in the same branch :) Tested on a few repos, works fine for me. Congrats! Merged into devel. I would have merged into testing too, if the branch wasn't branched off devel. Will be in 0.23 instead of 0.22.1, no big deal. Ok. Will you create the two tickets for the remaining repos (IUK and perl5lib), blocked respectively by #6450 and #6459, or should I? I have created them. Apparently I didn't have permissions yet to set proper blocked by, so I just left that as comments for now. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Make all .desktop-files translatable in Transifex
I just filed ticket #6470, https://labs.riseup.net/code/issues/6470: Currently one cannot translate the following desktop files through Transifex: - whisperback/data/whisperback.desktop - persistence-setup/share/applications/tails-persistence-setup.desktop - persistence-setup/share/applications/tails-persistence-delete.desktop - liveusb-creator/data/liveusb-creator-launcher.desktop - tails/config/chroot_local-includes/usr/share/applications/ tails-upgrader.desktop The tails-upgrader one can easily be added to the current workflow, but the other ones may either need to be moved to the main Tails repository, or have the desktop-translation functionality added to each of their own repository. Discuss the best way to make them translatable, and implement it. Implementing the same tricks we already do in the Tails main repository, using intltool to translate the desktop files, may not be that easy to do in the other repositories. I tried doing it with persistence-setup, but got stuck since I couldn't easily modify the build-script to generate the desktop files. It would be much easier to just move all these desktop files over to the main Tails repository, just like the tails-upgrader.desktop file already is, and just add them to the current translation workflow for desktop files. If this is an acceptable solution, I can implement it now. What do you think? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, take two, please review
intrigeri wrote: winterfairy wrote: See my tails repository, branch import-translations-extern. [...] Here's an initial code review. Instead of: SCRIPT_DIR=$(cd $(dirname $0) pwd) .. I would write the slightly nicer (to my eye): SCRIPT_DIR=$(readlink -f $(dirname $0)) Done in the same branch :) Regarding: - $GIT_IN_TOR_TRANSLATION_DIR fetch origin + eval $GIT_IN_TOR_TRANSLATION_DIR fetch origin ... why the need to use eval here? Same for: + eval $AFTER_IMPORT ... where: $AFTER_IMPORT would work, right? The reasons for the eval uses is because that is the proper way to execute a shell command stored in a variable [1], which is what we do in these cases. For $AFTER_IMPORT in liveusb-creator, the command would otherwise fail with (since is not interpreted correctly): make: s,\.new\$,,: No such file or directory make: *** No rule to make target `s,\.new\$,,'. Stop. Same for the git commands, the double-quotes in $GIT_IN_TOR_TRANSLATION_DIR are not interpreted correctly unless run in eval. [1] http://fvue.nl/wiki/Bash:_Why_use_eval_with_variable_expansion%3F ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, take two, please review
intrigeri wrote: I had a quick look at two of those. It does look good, but I must say the intense code duplication makes me wonder if we shouldn't instead add one single script to the Tails main repository, make it take the relevant parameters [...] What do you think? Maybe. I cannot see whether this would work any good or not, but I got interested, so I will try to put together such a script soon so we can compare. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Scripts for importing Transifex translations, take two, please review
Besides IUK and perl5lib for which Transifex resources still does not exist, I believe I have resolved ticket #6207: See branch import-translations in the following repositories (all based on respective master branch): - winterfairy/greeter - winterfairy/persistence-setup - winterfairy/liveusb-creator - winterfairy/whisperback I also updated the release process documentation, see branch import-translations-doc in my tails repository (based on devel branch). ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge bugfix/back-to-linux-3.10 [Was: Fix sdmem on Intel graphic hardware, please review]
intrigeri wrote: I just run a bunch of tests on three different laptops. Below, emergency means that I've removed the boot USB stick once the greeter appeared, applet means that I've used the GNOME panel applet to shutdown the system, and N/M means N successes on M attempts. ThinkPenguin Royal: * 0.22~rc1: emergency = 0/3, applet = 0/3 * bugfix/sdmem_on_intel_gpu: emergency = 0/3, applet = 0/3 * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 ThinkPad X201: * bugfix/sdmem_on_intel_gpu: emergency = 1/3, applet = 1/3 * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 ThinkPad X32: * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 So, I'm hereby requesting a review'n'merge of bugfix/back-to-linux-3.10 into testing and devel (there's an APT merge to do, too). bertagaz will take care of it. Merged into experimental, pushed to origin and lizard so the next nightly build from experimental will have this stuff. Once this branch is merged, I'll file a ticket to unblock the situation later, as we can't ship Linux 3.10 forever, and will edit the call for testing 0.22~rc1 so that we get feedback from non-Intel-graphics users and hopefully understand better who's affected exactly. My tests, applet only (success/total): * before any fix: 0/3 * sdmem_on_intel_gpu [1]: 2/3 * back-to-linux-3.10 [2]: 3/3 Apparently my fix does not fix it completely, so reverting to an older kernel version seems to be the most sane thing to do right now, yes. I won't try to fix this problem anymore, so unless anyone else is up to it, we have to hope a future linux kernel version works again. I believe the underlying problem is that kexec doesn't play well with all drivers/hardware, since they are not properly deinitialized or cannot be properly deinitialized, leaving memory-mapped regions the newly loaded kernel does not know about. The longstanding known issues page lists similar problems for other computers, some with non-Intel graphic hardware. [1] tails-i386-experimental-0.23-20131202T0830Z-07817d7.iso [2] tails-i386-experimental-0.23-20131202T1339Z-92b9fbb.iso ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
intrigeri wrote: winterfairy wrote: For the other repositories: The bug says something about Makefile targets, but it is okay that it is a script, right? And that the user must manually invoke the script to pull translations, just like in the tails repo right now? I think it's a very good first step. Do you think it is enough to resolve the ticket (#6207)? For the Perl software, I'll probably integrate running this script into the automated Dist::Zilla release workflow, but I guess it's fine to require the person doing the release to run an additional command here and there. It is easier for me to just add the script (and adjust it for this repository and po-style). If that is enough to resolve the ticket, I will not spend much work on trying to integrate it with any automated release workflows, unless it is somewhat obvious to me how to integrate it. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Fix sdmem on Intel graphic hardware, please review [Was: Shutdown stopped working in nightly experimental?]
winterfairy wrote: I still believes what I said about overwriting something it shouldn't, and now I also believe it is directly Intel graphic card related. These are still guesses though, I may be wrong. Fixed in bugfix/sdmem_on_intel_gpu (based on devel) in my repo :D Please test that it fixes it for you too, and please verify that the memory still is wiped. If that is the case, the screen corruption I had and this regression was related. The screen corruption does not occur anymore, and I actually get erasing progress written with * during erasing, something I didn't knew existed :) The i915 driver (and its dependencies) must be loaded before sdmem starts wiping. I guess the problem was that the GPU still believed the video memory was mapped to a System RAM region, but the kernel thought that memory was unused. By loading the driver it is reinitialized properly. PS: only tested by patching the affected ISO, I haven't really built the branch. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
intrigeri wrote: winterfairy at riseup.net wrote (30 Nov 2013 19:00:56 GMT) : There was a purpose of the code in import-translations that was removed by commit: e76059cd74bec591d7104b65e3f188e43a36ef7f Commits b2a3952 and d62bf4c (directly pushed to devel, sorry) should restore the intended behavior back, with a slightly different implementation (factorized functionality from refresh-translations into our shell library). Does this achieve the result you intended? It seems so, yes. If you wait with reviewing the greeter repository, I can rebase it with an import-translations script that more closely resembles the one now in the tails repo. Would this be good? For the other repositories: The bug says something about Makefile targets, but it is okay that it is a script, right? And that the user must manually invoke the script to pull translations, just like in the tails repo right now? Sorry if many questions, but I don't want to redo the work again just because it should have been done differently, since it is many repositories. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shutdown stopped working in nightly experimental?
Sorry for the delay, mailing list archives was offline, or whatever... intrigeri wrote: I can reproduce winterfairy's results on a ThinkPad X201 (both with the shutdown applet and with the emergency shutdown). FWIW, both this system and the ThinkPenguin Royal have Intel graphics. I can't reproduce this issue in libvirt/qemu (qxl graphics). winterfairy, what graphics driver is used by the system exposing this bug? lspci: 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03) (using i915 driver according to lsmod) I've seen no indication that the kernel has finished loading and run the initramfs' init. I haven't checked if the memory wipe did happen or not. I fear we have to treat this as a serious regression. Was hoping it was just my computer... :( Was there important security fixes in the new kernel version, or is it possible to revert the kernel upgrade if the cause is not found promply enough? [list of TODO items] winterfairy, do you think you can take care of any of this in the next few days (say, before next Tuesday)? I doubt it, will be kind of busy until Thursday. intrigeri wrote: winterfairy wrote: This makes me believe the memory erasing acts badly with this kernel version and hardware combination, possibly writing some data somewhere it shouldn't had, causing the kernel or hardware to force a reboot. And that it worked with previous kernel versions on this hardware by pure luck. My understanding is that sdmem shouldn't be allowed to write to places it shouldn't. Changes in the OOM area, perhaps? I want to look deeper into this, but I cannot find where the actual memory erasing code is (where sdmem is started?)? Only where the kexec bits are. Where is it? You want to look at https://tails.boum.org/contribute/design/memory_erasure/ and /usr/share/initramfs-tools/scripts/init-premount/sdmem intrigeri wrote: I'm more and more inclined to think it's a regression in Linux itself. I still believes what I said about overwriting something it shouldn't, and now I also believe it is directly Intel graphic card related. These are still guesses though, I may be wrong. But, previously on my computer, the screen was always scrambled during memory erasure. The exact pattern sometimes varied between Tails releases, but it was just scrambled. Expected, maybe, since the video memory is RAM mapped. But a few releases back, when Tails switched to a much newer Linux kernel, the scrambling stopped, and I instead got blue twinkling stars (pixels actually) during the erasure procedure. Now, how is that possible, unless the video card is put in some absurd state? And now it broke? So, I will look into that sdmem script and see if there is something odd there, for starters. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
intrigeri wrote: winterfairy at riseup.net wrote (29 Nov 2013 14:14:46 GMT) : Please review and merge: - repo winterfairy/tails, branch import-translations (based on devel) Merged and pushed some refactoring commits on top. There was a purpose of the code in import-translations that was removed by commit: e76059cd74bec591d7104b65e3f188e43a36ef7f The purpose was, if one run import-translations and then commits (without running refresh-translations), there will show up much changes in all po-files, even if no changes really was made. That makes it harder to track how the content in the po-files have changed. Running intltool-update is fast, so it being run twice is not a big problem for that reason. And I believe it should be run in import-translations too, just to make the logs more clean in those cases someone commit immediately after import. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Scripts for importing Transifex translations, please review
I have started working on bug #6288, automating the Update PO files step of the release process. This is done with a new import-translations script that automatically import completed translations from Transifex (through torproject.org:translation.git), except for French and Portuguese (Brazil). The actual release process document is also updated. Please review and merge: - repo winterfairy/tails, branch import-translations (based on devel) - repo winterfairy/greeter, branch import-translations (based on master) I have only finished the work on those two repositories yet, but I want to have it reviewed so I know I am doing it right before I do it for the rest of the repositories too. By the way: The mailing list archives are down: Service Temporarily Unavailable. I cannot view any replies, nor temporarily subscribe to the list. Please CC me. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fix for keyboard layouts in the greeter, please review
intrigeri wrote: winterfairy at riseup.net wrote (24 Nov 2013 14:02:00 GMT) : https://bugs.freedesktop.org/show_bug.cgi?id=71963 Awesome :) And now merged :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Shutdown stopped working in nightly experimental?
intrigeri wrote: winterfairy at riseup.net wrote (22 Nov 2013 12:23:14 GMT) : It seems Shutdown immediately and Reboot immediately both reboots the system in current nightly builds of experimental. I can confirm the system reboots with a recent build from experimental, when using the emergency shutdown feature (unplugging the Tails USB stick) on a ThinkPenguin Royal laptop. Different issue? Maybe caused by the same regression? I suspect the upgrade to Linux 3.11 is the cause, as the other probable cause (initramfs-tools 0.115) only brings changes that seem unrelated. After some more testing on the ISO I had, I too believes it is caused by the kernel upgrade. But I do not think it is the kernel's fault. When it reboots even though I selected shutdown, it actually does not reboot properly. It reboot early in the memory erasing procedure (possibly in the beginning) and leaves the memory unerased. This makes me believe the memory erasing acts badly with this kernel version and hardware combination, possibly writing some data somewhere it shouldn't had, causing the kernel or hardware to force a reboot. And that it worked with previous kernel versions on this hardware by pure luck. I want to look deeper into this, but I cannot find where the actual memory erasing code is (where sdmem is started?)? Only where the kexec bits are. Where is it? winterfairy, can you please try and reproduce this with a pre-3.11 experimental build if you still have one around? I don't have any :( ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fix for keyboard layouts in the greeter, please review
intrigeri wrote: Merged, thanks! Nice :) Anyway, since it's fixed upstream, I'm happy to take the temporary kludge, with some marker in the code so that we revise it for Jessie (I'll add the markers, don't worry). Ok. I'll update feature/spoof-mac and the package in experimental shortly. I've not built new .deb's for Wheezy yet, and don't plan to do it until I work on feature/wheezy again. Ok. * Norwegian is not fixed upstream. I suppose I can submit a patch to them that fixes it. Yes, please. I have created a patch and tested that is does what I expects it to, only actually submitting it upstream remains. \o/ https://bugs.freedesktop.org/show_bug.cgi?id=71963 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fix for keyboard layouts in the greeter, please review
intrigeri wrote: winterfairy wrote: intrigeri wrote: winterfairy wrote: I am a bit uncertain, as recently hrv has been added for the keyboard layout us/hbs (serbo-croatian (us)). I do not really know if hr (croatian) keyboard layout is preferred for croatia. Fedora installer selects hr it seems. It would be awesome to have these uncertainties cleared, There are a few Croatian translators on Tor projects Transifex page. I will go ahead and ask them, they would know the best. Perfect. Good news, Croatian is already fixed upstream! No idea how I missed that :) xkeyboard-config commit ffed69dc, on Feb 1 2013, released as version 2.9. Latest release is 2.10.1. Squeeze has version 1.8. Wheezy and experimental has version 2.5.1. Latest X.org release has 2.6. So in a few years from now, maybe, it reaches us :) Unless something can be done on Debian's side of things. * Norwegian is not fixed upstream. I suppose I can submit a patch to them that fixes it. Yes, please. I have created a patch and tested that is does what I expects it to, only actually submitting it upstream remains. [on topic of sardinian keyboard layout] I think I'd rather not fixed a problem that nobody is affected by... and the day we receive a complain, then we'll learn at the same time what is their preferred keyboard layout :) Agree. Should I rebase my branch without the Sardinian commit, or revert it? In general, I prefer if you revert it. (I personally dislike having to review a branch entirely again due to history rewriting. I might squash the branch to make its history cleaner — without content change — before merging, if I think of it at that time.) Done. So, the Norwegian and Croatian fix should go in for the next Tails release. I have updated both my branches bugfix/norwegian-layout and bugfix/norwegian-layout-wheezy by reverting the Sardinian commit and merging into the wheezy one. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Shutdown stopped working in nightly experimental?
It seems Shutdown immediately and Reboot immediately both reboots the system in current nightly builds of experimental. Known issue? I have not investigated it further. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1
intrigeri wrote: Kill Your TV wrote (21 Nov 2013 02:06:30 GMT) : intrigeri intrigeri at boum.org wrote: Kill Your TV wrote (14 Nov 2013 20:32:45 GMT) : If ACLs can be used [...] I've no idea if they're available for SquashFS, especially once combined with aufs. One would have to test this. Let's perhaps keep this for a future iteration, though, and make sure it does not block the basics from landing into 0.22. Works for me. Great! So a future iteration can bring back the UX improvements, without hindering security more than necessary :) The rsync command currently used for creating IUK packages maybe won't copy/preserve ACLs. A flag like -A or -X may be needed. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fix for keyboard layouts in the greeter, please review
intrigeri wrote: winterfairy wrote: I am a bit uncertain, as recently hrv has been added for the keyboard layout us/hbs (serbo-croatian (us)). I do not really know if hr (croatian) keyboard layout is preferred for croatia. Fedora installer selects hr it seems. It would be awesome to have these uncertainties cleared, There are a few Croatian translators on Tor projects Transifex page. I will go ahead and ask them, they would know the best. * Sardinian is not a selectable language in Fedora installer or Ubuntu installer, and we do not know which keyboard layout it should use. It is not fixed upstream. We cannot fix it upstream. Should I file a bug report that it is missing? I've found no ML for Sardinian in Debian either. Did anyone actually complained about Tails' default keyboard layout for Sardinian? In bug #5741, it says: The following languages only get the USA layout, [...] * [...] * Sardinian (should get Ita (Italian) perhaps?) * [...] It sounds like someone tried selecting random languages in the greeter until they found one that only got the USA fallback layout. And I can find no Sardinian translators on Tor projects Transifex page either. If not, I think I'd rather not fixed a problem that nobody is affected by... and the day we receive a complain, then we'll learn at the same time what is their preferred keyboard layout :) Agree. Should I rebase my branch without the Sardinian commit, or revert it? Or maybe rebase my branch with only the norwegian fix, so it definitely makes it for the next Tails release? I really wanted to fix the norwegian keyboard support for the next Tails release, the other languages were just a bonus as they belonged to the same bug report. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Smaller IUK packages
You can make the IUK packages smaller by replacing rsync --archive --quiet --delete-after with rsync -rlpgoD --checksum --quiet --delete-after This since many files currently is copied even if they actually haven't changed, only had their timestamp updated (maybe because timestamp is set to date the dpkg package was installed, because generated by a script, or something). By the above modification I produced a squashfs delta between Tails 0.18 and Tails 0.21 that was just 187 MB, something xdelta between the ISO files confirmed is the best one can do without further tricks. I don't know how large that squashfs delta was before the change, because my computer OOM'ed every time I tried building it (tmpfs, and too little ram). I have *not* actually tried running the produced squashfs delta. Timestamps is not updated anymore with this change, but I doubt any application relies on them. But this has to be tested by whoever investigate this further. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Fix for keyboard layouts in the greeter, please review
My branch bugfix/norwegian-layout in my winterfairy/greeter repo fixes bug #5741. Nynorsk and norsk bokmål (both version of norwegian) now gets norwegian keyboard layout, sardinian now gets italian keyboard layout, and hrvatski (croatian) now gets croatian keyboard layout. Portuguese/brazil already worked, as mentioned in that bug ticket. That branch is based on the master branch. I have also a version with this branch merged into the wheezy branch, see bugfix/norwegian-layout-wheezy. All the issues my fix fixes were present in wheezy too, and fixed by my patch. But basically, the issues are that upstream (xklavier, xkb or x11) does not support the languages, we were polling for them in the right way. My fix only hacks around upstreams lack of support. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Switched to IBus in squeeze too, please review
In branch bugfix/ibus in my repo winterfairy/tails, which is based on tails testing branch, there is patches that replaces SCIM with IBus, much like I did for wheezy. The most important reason for this is to fix bug #6206, which made it impossible to use pinentry when logging in with Chinese, Japanese or Korean. This also fixes all points in bug #5624, I believe. There was some uncertainity whether IBus works well in squeeze. All input methods I tested, in all applications I tested them in, for all languages I tested, worked just like I believe they should. Not a single crash or unexpected behaviour. If there is unstability, it will probably not show itself unless used by experienced users for a longer time. I still believe switching is the right thing to do, as SCIM makes GnuPG almost unusable. And we are switching to Wheezy soon enough anyway. I also added bopomofo for chinese, as it seems to be more popular than pinyin in some regions. This I also did in the branch bugfix/ibus-wheezy in my repo, so it need to be reviewed and merged again too. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Switched to IBus in squeeze too, please review
intrigeri wrote: winterfairy at riseup.net wrote (07 Nov 2013 09:47:30 GMT) : In branch bugfix/ibus in my repo winterfairy/tails, which is based on tails testing branch, there is patches that replaces SCIM with IBus, much like I did for wheezy. Great! Reviewed (looks good, I just wonder what package installs bopomofo support, so building an ISO to verify), will test it today. Don't know, I guess it comes with ibus-pinyin, but it may be from a dependency to ibus-pinyin. Did you figure it out, or should I research it? When submitting such a review'n'merge request, please reassign the relevant ticket to the release manager (for 0.22, that's me) and set QA Check to Ready for QA. I will do that next time :) I also added bopomofo for chinese, as it seems to be more popular than pinyin in some regions. OK. Any reason why the preflist isn't set to pinyin,bopomofo,anthy,hangul for Chinese locales, instead of the default pinyin,anthy,hangul,bopomofo? No, except that the first place is the only one that really matters. All the other ones have to be selected either way. Should I change this? I guess it would make sense to group the chinese input methods together. This I also did in the branch bugfix/ibus-wheezy in my repo, so it need to be reviewed and merged again too. I notice the commits are different on bugfix/ibus and bugfix/ibus-wheezy. I guess you cherry-picked them, Correct. which will result in hard to understand history next time devel is merged into feature/wheezy. I understand it was hard to do otherwise, since the initial development (bugfix/ibus-wheezy) was based on feature/wheezy. Next time you prepare changes that should land both into devel and feature/wheezy, please base $TOPIC_BRANCH off devel, and if you're extra nice, create a $TOPIC_BRANCH-wheezy branch that starts from $TOPIC_BRANCH, merges feature/wheezy into it, and solves any conflict along the way. I will do it like that next time. For this time, it's too late since the original branch was already merged into feature/wheezy. No big deal anyway :) :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Switched SCIM to IBus for wheezy, please review
intrigeri wrote: This stuff (+ 2 minor polish commits of mine) can be tested in: [...]/tails-i386-feature_wheezy-0.22-20131105T0917Z-30e8c3c.iso Ok. I wonder if we really want to start the ibus daemon and applet unless logged in with a locale that needs one of these input methods, so I've not marked the ticket as resolved yet. Thoughts? Bug #5624 seems to indicate we want to start the IBus daemon always, since it must be started at login time to be fully usable (environment variables must be set up). See mentions of restart X in that bug report, and final dot under research. One may want to input in Chinese, Japanese or Korean even when selecting English as language, for example when working on documents. I think it should be started by default, especially since I cannot see how it may interfere for users that are not going to use it. What would any reason for not starting it by default be? Anyone have any? I will wait with fixing this issue in squeeze based Tails until we have decided whether to start it always by default or not. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Wheezy build ISOs available?
intrigeri wrote: Alan wrote (05 Nov 2013 10:32:36 GMT) : It doesn't (greeter fails to start), python backtrace in the logs. Thanks for testing. Should now be fixed, triggering a Jenkins build. I can confirm it now works, and that my patches works as they should in Wheezy too. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Clock v0.3 - Update
intrigeri wrote: winterfairy wrote: Kevin wrote: winterfairy wrote: If standalone like now, we need to get Runa or someone to add a new translation resource on Transifex for it. In this case, which repository and which branch should we be tracking the pot file in? tails at git.tails.boum.org:kevin/clock.git The stable branch is master. If I get the clear sign from a higher-up Tails dev that this is the way to do it, I volunteer to contact Runa and get it added. :) I confirm this is the right way to do it. However, it seems a tiny bit premature to me: to avoid translators doing unnecessary work, I suggest we only do that once the applet has sajolida has had time to review the UI and the strings. Ok, then we'll wait for that. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Wheezy build ISOs available?
Are there any ISO files of recent wheezy builds of Tails available for download somewhere? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tails Clock v0.3 - Update
Kevin wrote: Would changing the label to read: Display AM/PM time? be suitable? [...] Some locales don't have AM/PM at all, some default with seconds, others don't ... LANG=sv (Swedish, as I tested) does not have AM/PM, only 24-hour time. Apparently AM or PM is not written after the clock. E.g. instead of 10.34 AM, only 10.34 is displayed, even with 12-hour clock enabled. I think having 12-hour clock disabled by default for Swedish would be preferable, but I don't know if locale specific default settings is easy to do. Kevin wrote: Preferences and About are using the stock GNOME items and so don't need to be translated within Tails Clock itself. Actually they seems not to be for Gtk2, see create_menu2 in TailsClockApplet.py. Only the icon seems to be set as stock. Either way, relying to stock items for translations is in my opinion bad practice. What if the stock translation is missing? When the whole applet cannot be translated! I think it would be better if you used only the stock icons, and made the actual strings translatable. This is what I usually do, and seems to be what the current GNOME clock do :) Reason: Consistency. (gnome-panel-2.30.2/applets/clock/GNOME_ClockApplet.xml gives example of how to make it translatable, I think.) Kevin wrote: The root of the problem here is the locale-dependent strftime string. Typically these are in the form of %a %b %e %H:%M:%S or something along those lines. [...] Programmatically supporting this is impractical which led me to examine the source code for the official GNOME panel clock applet. Basically, they support the formats via translation strings. I will now head down the path of supporting the date/time formats via translation strings. This sounds like a good solution to me. As a bonus, I'll follow the same design pattern as the GNOME clock applet and we can borrow the translation strings from them (both projects being GPL, I don't believe this should be an issue, please correct me if I'm wrong). This should be fine, yes. Kevin wrote: winterfairy wrote: Is this clock applet supposed to be a standalone deb, like now, or is it supposed to be merged into the tails repository with all other tiny utilities we have? intrigeri? As far as I know, it's built for Tails but is a stand-alone project. If standalone like now, we need to get Runa or someone to add a new translation resource on Transifex for it. In this case, which repository and which branch should we be tracking the pot file in? tails at git.tails.boum.org:kevin/clock.git The stable branch is master. If I get the clear sign from a higher-up Tails dev that this is the way to do it, I volunteer to contact Runa and get it added. :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Fixed default country and applying of pt_BR translation in tails-greeter
Here is seven patches against the master branch in tails-greeter.
0001-Language-and-syntax-fixes.patch
0002-Added-new-file-default_langcodes.patch
0003-Install-default_langcodes-and-read-it-in-first.patch
0004-Sort-the-default_langcodes-file-and-really-only-list.patch
0005-Remove-old-incorrect-way-of-inferring-default-countr.patch
0006-Take-country-code-into-consideration-when-translatin.patch
0007-Prefer-keyboard-layout-for-selected-country.patch
The current behaviour of Tails Greeter:
- Select Swedish, and Finland is chosen as country.
- Select Portuguese, and Portugal is chosen as country.
- Select Portuguese/Brazil, and the translation is not applied.
The new fixed behaviour:
- Select Swedish, and Sweden is chosen as country.
- Select Portuguese, and Brazil is chosen as country.
- The translation for Portuguese/Brazil is applied correctly.
I am a bit uncertain about the change to Brazil as default country
for Portuguese, but we only have a pt_BR translation, and Wikipedia
supports my intuition that Portuguese is mostly spoken in Brazil.
Some more languages had their default country changed.
The list used is taken from the Ubuntu installer, so the
default choices should be sensible.
It would also make it easier for me to continue contribution
small bugfixes if I either get push access to the greeter and
tails repository, or get my own clones of those repositories with
push access. That way I don't have to send patches, but can request
review and merge of branches instead. Possible?From 4a9824cb2150071bd2dc9b3ecddee044805c6447 Mon Sep 17 00:00:00 2001
From: WinterFairy winterfa...@riseup.net
Date: Sat, 2 Nov 2013 14:11:12 +
Subject: [PATCH 1/7] Language and syntax fixes
---
GdmGreeter/language.py |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/GdmGreeter/language.py b/GdmGreeter/language.py
index d489f13..eda5d3d 100644
--- a/GdmGreeter/language.py
+++ b/GdmGreeter/language.py
@@ -18,7 +18,7 @@
# You should have received a copy of the GNU General Public License
# along with this program. If not, see http://www.gnu.org/licenses/
#
-Localistaion handeling
+Localization handling
@@ -65,7 +65,7 @@ def get_native_langs(lang_list):
langs_dict = {}
for l in lang_list:
# English = Locale(en_GB)...
-lang = Locale(l).getDisplayLanguage(Locale(l)).title()
+lang = Locale(l).getDisplayLanguage(Locale(l)).title()
try:
langs_dict[lang]
except: #XXX specify exception
@@ -513,8 +513,8 @@ class LocalisationSettings(object):
# List of system locale codes
langcodes = __get_langcodes()
-# dictionnary of native language: language code
+# dictionary of native languages: language code
_languages_dict = get_native_langs(langcodes)
-# dictionnary of layout codes: layout name
+# dictionary of layout codes: layout name
_system_layouts_dict = __fill_layouts_dict()
--
1.7.2.5
From 24c339ab97ff57bc2ffba138178ef2b5f3ca73be Mon Sep 17 00:00:00 2001
From: WinterFairy winterfa...@riseup.net
Date: Sat, 2 Nov 2013 15:21:44 +
Subject: [PATCH 2/7] Added new file default_langcodes
This file lists the default language country pairs,
e.g. en_US or sv_SE. This is needed because the latter
is currently incorrectly set to sv_FI when sv is selected,
for example.
The list was derived from a similar file in Ubiquity,
which in turn appears to have derived it from
Debian Installer's localechooser.
---
default_langcodes | 74 +
1 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 default_langcodes
diff --git a/default_langcodes b/default_langcodes
new file mode 100644
index 000..a9f3361
--- /dev/null
+++ b/default_langcodes
@@ -0,0 +1,74 @@
+sq_AL
+am_ET
+ar_EG
+ast_ES
+eu_ES
+be_BY
+bn_BD
+bs_BA
+br_FR
+bg_BG
+bo_IN
+ca_ES
+zh_CN
+zh_TW
+hr_HR
+cs_CZ
+da_DK
+nl_NL
+dz_BT
+en_US
+et_EE
+fi_FI
+fr_FR
+gl_ES
+ka_GE
+de_DE
+el_GR
+gu_IN
+he_IL
+hi_IN
+hu_HU
+is_IS
+id_ID
+ga_IE
+it_IT
+ja_JP
+kk_KZ
+km_KH
+kn_IN
+ko_KR
+ku_TR
+lo_LA
+lv_LV
+lt_LT
+ml_IN
+mr_IN
+mk_MK
+my_MM
+ne_NP
+se_NO
+nb_NO
+nn_NO
+fa_IR
+pl_PL
+pt_PT
+pt_BR
+pa_IN
+ro_RO
+ru_RU
+si_LK
+sr_RS
+sk_SK
+sl_SI
+es_ES
+sv_SE
+tl_PH
+ta_IN
+te_IN
+th_TH
+tr_TR
+ug_CN
+uk_UA
+vi_VN
+cy_GB
--
1.7.2.5
From 6257fd77c64e965eefd060570e17ceea8e197863 Mon Sep 17 00:00:00 2001
From: WinterFairy winterfa...@riseup.net
Date: Sat, 2 Nov 2013 16:12:49 +
Subject: [PATCH 3/7] Install default_langcodes, and make use of it.
By reading it in before the complete language_codes file,
those default will end up first in the list over language codes,
and have precedence when selecting language.
---
GdmGreeter/config.py |3 +++
GdmGreeter/language.py |4 +++-
debian/rules |2 ++
3 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/GdmGreeter/config.py b/GdmGreeter/config.py
index da90d21..a5e725f 100644
--- a/GdmGreeter/config.py
+++ b/GdmGreeter/config.py
Re: [Tails-dev] Tails Clock v0.3 - Update
Kevin wrote: [1] http://kevin.c.krinke.ca/builds/tailsclock/tailsclock_0.3-1_all.deb I tested simply installing this deb in a running Tails and adding the applet to the panel. I saw the following problems: - Seconds are showing by default, eg 10.25.47. The checkbox Display seconds? is not ticked however. - The clock is not updated, it keeps displaying 10.25.47 for a whole minute. Unless I tick the box Display seconds? - Unticking the box again does not remove the seconds, but stops the clock updating again. Also, I am not certain what 12 hour clock is supposed to do? Shouldn't that one write AM or PM or something like that, because it is not for me. GNOME's default clock applet doesn't even allow me to enable 12 hour clock, it is always 24 hour clock, so I cannot compare. My current locale is LANG=sv_FI.UTF8. Kevin wrote: * Test locales properly (need help with this! any volunteers?) * Translations? (used google translate so far for strings) First, please move the tailsclockapplet.pot to locale/, so it is not inside the en folder. The pot file is also missing the strings Tails Clock and A simple GNOME panel applet clock. (for which I prefer removing the final dot), Preferences and About (from the right-click menu). We use Transifex for translation. Is this clock applet supposed to be a standalone deb, like now, or is it supposed to be merged into the tails repository with all other tiny utilities we have? intrigeri? If standalone like now, we need to get Runa or someone to add a new translation resource on Transifex for it. In this case, which repository and which branch should we be tracking the pot file in? ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Should we avoid using the word bug?
On 05/09/13 18:54, intrigeri wrote: sajol...@pimienta.org wrote (05 Sep 2013 16:23:33 GMT) : So, my proposal is to use error sometimes, but keep bug once the ambiguity has be cleared. And to do that: 1. Change the desktop shortcut and the title of the documentation page to Report an error. 2. Change Exact steps to reproduce the problem to Exact steps to reproduce the error. 3. Change Actual result / the problem to Actual result, the error. In this plan, I don't see where bug is used once the ambiguity is cleared. May you please clarify? The word bug will still be used as until now on the page https://tails.boum.org/doc/first_steps/bug_reporting/, and in the intro text of Whisperback. Does that make sense or do you think it will be confusing to have only the title of the page and the launcher talk about error instead of bug; winterfairy, what do you think about all that? I still don't like the word bug, and other software doesn't seem to use the word bug in interfaces for casual users. Also, consistency. But I'm ok with it being used after the ambiguity is cleared, like the proposal above. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Should we avoid using the word bug?
Hi. I want to propose some wording improvements for whisperback and corresponding documentation. Right now, the desktop icon read as Report a bug. Bug is a real and recognized word for software error, but it is also a real and recognized word for a kind of surveillance device secretly recording audio [1]. I therefore believe that the word bug may be confusing in the context of Tails. I don't know what applies for English, but in Swedish non-technical people tend to believe you talk about the listening device when you say bugg. I think this mistake may exist in more languages, so I propose to change the desktop icon to read as Report an error instead. Likewise I want the text inside whisperback that now reads Help us fix your bug! to read Help us fix your software error! or even Help us fix your software bug!. And similar for other instances of the word bug. If you do not think English speaking people can misunderstand the word bug in this context, I will simply change it in the Swedish translation only. Thoughts? [1] http://dictionary.reference.com/browse/bug ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/intltoolize
Hi. intrigeri wrote: ... This next step is now implemented in feature/intltoolize, based upon feature/merge-pot-files. It would make sense to review and merge both at the same time. Candidate for 0.19.1 or 0.20, whichever comes first = please review and merge into devel, and into stable once 0.19 is out. Once these branches are in, all translatable strings that live in our main Git repository (apart of the website) are managed in a single PO file per language. Given all translatable files were moved around in these branches, and translations all alike, it would be great to merge them before translators send us diverging changes that would be a pain to forward-port. Thanks! Something went wrong in this branch. Checking the swedish translations the following two errors exists (po/sv.po): #: config/chroot_local-includes/usr/local/bin/tails-start-i2p:82 #: config/chroot_local-includes/usr/local/bin/tails-start-i2p:124 #, fuzzy msgid I2P failed to start msgstr Misslyckades med att starta om Tor. #, fuzzy #~ msgid check Tails known security issues #~ msgstr Det finns kända säkerhetsproblem i den här Tails versionen: Neither of these two strings were translated before, and the translations they have belong to other strings. A similar error for french appears to be fixed in commit 4bf73de454. Maybe this error happened for all languages. Anyway, I'm looking forward to when all this work is done and imported in Transifex :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/intltoolize
intrigeri wrote: Hi, winterfa...@riseup.net wrote (24 Jun 2013 10:46:42 GMT) : Something went wrong in this branch. Checking the swedish translations the following two errors exists (po/sv.po): #: config/chroot_local-includes/usr/local/bin/tails-start-i2p:82 #: config/chroot_local-includes/usr/local/bin/tails-start-i2p:124 #, fuzzy msgid I2P failed to start msgstr Misslyckades med att starta om Tor. #, fuzzy #~ msgid check Tails known security issues #~ msgstr Det finns kända säkerhetsproblem i den här Tails versionen: Neither of these two strings were translated before, and the translations they have belong to other strings. Your attention to detail is very much appreciated! As far as I can tell: - No existing work was lost, was there? - These are merely *fuzzy* strings, that is guesses that gettext tools made based on strings similarity, to help translators do their job. E.g. I guess you could take the Misslyckades med att start om Tor approximate translation, s/Tor/I2P/, remove the fuzzy annotation and be done with it, isn't it? These automatic translation suggestions are normally *not* used in practice by actual programs. If they are, then that's a bug that should be reported. So, I believe there's no actual problem to solve, right? :) Didn't know about fuzzy strings. Then it indeed seems there is no actual problem :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Remove Iceweasel popups that confuse users
intrigeri wrote: Hi winterfairy, intrigeri wrote (25 May 2013 14:08:39 GMT) : winterfa...@riseup.net wrote (25 May 2013 12:20:08 GMT) : This patch removed the following Iceweasel prefs from Tails: - security.warn_leaving_secure OK, I'm now convinced this one is overkill :) Do you want to resubmit a patch that removes this pref, or should we do it ourselves? I do not have a git clone of Tails main repo right now, and cloning it takes a while :/ (It should be quite trivial, but still, I have other ways to get busy, and I don't want to steal the work you have started :) Just do it. I do not care about credit and stuff, even if this would not have been trivial. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Added support for keeping entry guards
The following patches introduce support for persisting /var/lib/tor. The
primary benefit of this is the improved security/anonymity by keeping ones
Tor entry guards. But there is bootstrap and circuit speed benefits too.
Read the commit summaries for reasoning and explanation.
Please review, and tell me if there is something you want to be done
differently.
I tested the following: The entry guards are now persisted and Tor works
as it should, verified using Vidalia's network map and Wireshark. I also
tested mounting the persistent volume in read-only mode, and that also
works as a writeable overlay seems to be mounted over the read-only data.
I also tested bridge mode, and it seems not to break with this enabled,
but of course it is useless in bridge mode and just leaves unnecessary
traces. And finally I also verified that if I give the folder bad
ownership it is corrected as it should (see patch summary for why).
Patches against persistent-setup (master branch):
0001-Add-preset-for-persisting-Tor-entry-guards-and-Tor-c.patch
0002-Update-POT-file-to-include-new-strings.patch
Patches against tails-greeter (master branch):
0001-Fix-ownership-of-var-lib-tor-after-login-before-Tor-.patch
From 55f6263fc4a9bca88ac8cf9a6af3e6478d1afa2f Mon Sep 17 00:00:00 2001
From: Tails developers ta...@boum.org
Date: Sat, 25 May 2013 12:56:11 +
Subject: [PATCH 1/2] Add preset for persisting Tor entry guards (and Tor cache).
This preset provide important anonymity attack resistance
for those users who do not use bridges and do not worry
about being fingerprinted locally by the ISP or network
admin by which guards is used (like a MAC address).
It is disabled by default since Tails aim at being amnesic
by default.
Important: This depends on that tails-greeter fix the
ownership of the persisted folder, as Tor user's
UID/GID may change between Tails releases.
---
lib/Tails/Persistence/Configuration/Presets.pm | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/lib/Tails/Persistence/Configuration/Presets.pm b/lib/Tails/Persistence/Configuration/Presets.pm
index 43a450f..0723abd 100644
--- a/lib/Tails/Persistence/Configuration/Presets.pm
+++ b/lib/Tails/Persistence/Configuration/Presets.pm
@@ -55,6 +55,16 @@ method _build__presets {
icon_name = 'stock_folder',
},
{
+name= $self-encoding-decode(gettext(q{Tor Entry Guards})),
+description = $self-encoding-decode(gettext(
+q{Keep entry guards for better anonymity}
+)),
+destination = '/var/lib/tor',
+options = [ 'source=tor-state' ],
+enabled = 0,
+icon_name = 'vidalia',
+},
+{
name= $self-encoding-decode(gettext(q{GnuPG})),
description = $self-encoding-decode(gettext(
q{GnuPG keyrings and configuration}
--
1.7.2.5
From ac35130e78359520e72b62f2ff47194185c915db Mon Sep 17 00:00:00 2001
From: Tails developers ta...@boum.org
Date: Sat, 25 May 2013 20:05:59 +
Subject: [PATCH] Fix ownership of /var/lib/tor after login before Tor is started.
This is needed in case this folder is persistent, as the
numeric ids for debian-tor may change between Tails versions.
A find trick is used instead of chown -R so we avoid
some disk writes when the permissions already is right.
---
PostLogin.default | 13 +
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/PostLogin.default b/PostLogin.default
index aa8f87f..f7a5eba 100755
--- a/PostLogin.default
+++ b/PostLogin.default
@@ -61,10 +61,6 @@ if [ -z ${LIVE_USERNAME} ] ; then
log_n_exit Username variable not found.
fi
-
-### (re-)start services that need to wait for post-login time
-service network-manager restart
-
### Camouflage
CAMOUFLAGE_SETTINGS=/var/lib/gdm3/tails.camouflage
@@ -110,6 +106,15 @@ else
log_n_exit '/usr/local/sbin/tails-additional-software' does not exist or is not executable.
fi
+# Ensure the files in /var/lib/tor have correct ownership.
+# The Tor user's UID and GID may change between Tails versions,
+# and this directory may be persistent.
+# Important: Do this before running network-manager hooks.
+find /var/lib/tor ! -user debian-tor -o ! -group debian-tor | xargs chown debian-tor:debian-tor
+
+### (re-)start services that need to wait for post-login time
+service network-manager restart
+
### Password
# Import password for superuser access
--
1.7.2.5
From b423adae07ae03d272850f017daa6600fd01b8d5 Mon Sep 17 00:00:00 2001
From: Tails developers ta...@boum.org
Date: Tue, 28 May 2013 18:21:29 +
Subject: [PATCH 2/2] Update POT file to include new strings
---
po/tails-persistence-setup.pot | 112 +++
1 files changed, 55 insertions(+), 57 deletions(-)
diff --git a/po/tails-persistence-setup.pot b/po/tails-persistence-setup.pot
index 4908469..27fdbc1 100644
---
[Tails-dev] Remove Iceweasel popups that confuse users
This patch removed the following Iceweasel prefs from Tails: - security.warn_leaving_secure - security.warn_submit_insecure They are not set in either Firefox nor TBB, and users have reported them being very confusing in the context of Tails, see commit message and recent forum posts. From 5bc2b39354257751845f1e8788db8a5817ba0543 Mon Sep 17 00:00:00 2001 From: Tails developers ta...@boum.org Date: Sat, 25 May 2013 11:45:09 + Subject: [PATCH] Remove security.warn_* settings from Iceweasel profile. These preferences were never applied until the move to user.js for Tails 0.18. The dialog shown is confusing in the context of Tails, as many users falsely believes Tor gets disabled. Neither Firefox or TBB sets these, so remove them in Tails too. --- .../etc/iceweasel/profile/user.js |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/config/chroot_local-includes/etc/iceweasel/profile/user.js b/config/chroot_local-includes/etc/iceweasel/profile/user.js index f3eee33..aff09ec 100644 --- a/config/chroot_local-includes/etc/iceweasel/profile/user.js +++ b/config/chroot_local-includes/etc/iceweasel/profile/user.js @@ -136,6 +136,4 @@ user_pref(noscript.untrusted, google-analytics.com); user_pref(privacy.item.cookies, true); user_pref(privacy.sanitize.sanitizeOnShutdown, true); user_pref(security.xpconnect.plugin.unrestricted, false); -user_pref(security.warn_leaving_secure, true); -user_pref(security.warn_submit_insecure, true); user_pref(torbrowser.version, Tails); -- 1.7.2.5 ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Fix some translation related bugs in tails-greeter
Hi, winterfa...@riseup.net wrote (06 May 2013 12:54:51 GMT) : The following bugs in tails-greeter is fixed by the attached patches: Many thanks! Much appreciated :) I've applied these patches to tails-greeter master branch, built a snapshot .deb, uploaded it our `experimental' APT suite, and tested the result in a ISO image built from our experimental Git branch. Works fine for me. I plan to upload a proper release of tails-greeter that includes these patches, once Tails 0.18 is out, in the branch we'll use to prepare Tails 0.18.1 (stable) or 0.19 (devel) -- depending on what kind of next release we want. Ok, sounds great. If there is anything you prefer I do different when submitting patches in the future (e.g. use my own e-mail as commiter instead of tails), just tell me. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Fix some translation related bugs in tails-greeter
The following bugs in tails-greeter is fixed by
the attached patches:
* Forward button was not translatable.
* Forward button didn't use the intended icon,
but had the same icon as the Login button.
* If toggling more options on and off the Login button
ended up in English regardless of available translation.
* Wrong passphrase message for persistent volume
always ended up in English even when translation existed.
* Administrator password mismatch message always
ended up in English even when translation existed.
The last patch (0003) simply updates the pot-file, which needs to be
submitted to Transifex because of the added Forward string.
From 5a9618f019b5742c6d4ac121dbb087079e273810 Mon Sep 17 00:00:00 2001
From: Tails developers ta...@boum.org
Date: Mon, 6 May 2013 09:49:44 +
Subject: [PATCH 1/3] Fix so translations is applied on password mismatch messages
---
GdmGreeter/optionswindow.py |4 +---
GdmGreeter/persistencewindow.py |1 -
glade/optionswindow.glade |3 ++-
glade/persistencewindow.glade |3 ++-
4 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/GdmGreeter/optionswindow.py b/GdmGreeter/optionswindow.py
index 2c2965d..9042cb9 100644
--- a/GdmGreeter/optionswindow.py
+++ b/GdmGreeter/optionswindow.py
@@ -20,8 +20,7 @@
-import logging, gtk, gettext, os
-_ = gettext.gettext
+import logging, gtk, os
import GdmGreeter
from GdmGreeter.language import TranslatableWindow
@@ -65,7 +64,6 @@ class OptionsWindow(TranslatableWindow):
test_password = self.entry_password2.get_text()
passwords_match = test_password == auth_password
if not passwords_match:
-self.warning_label.set_markup(_('iPasswords do not match/i'))
self.warning_area.show()
return passwords_match
diff --git a/GdmGreeter/persistencewindow.py b/GdmGreeter/persistencewindow.py
index 7b21d21..3db106a 100644
--- a/GdmGreeter/persistencewindow.py
+++ b/GdmGreeter/persistencewindow.py
@@ -91,7 +91,6 @@ class PersistenceWindow(TranslatableWindow):
return True
except GdmGreeter.errors.WrongPassphraseError:
self.entry_passphrase.set_text('')
-self.warning_label.set_markup(_('iWrong passphrase. Please try again./i'))
self.warning_area.show_all()
return False
else:
diff --git a/glade/optionswindow.glade b/glade/optionswindow.glade
index 5c9cd51..9733f7c 100644
--- a/glade/optionswindow.glade
+++ b/glade/optionswindow.glade
@@ -209,7 +209,8 @@ Otherwise it will be disabled for better security./property
property name=xalign0/property
property name=xpad10/property
property name=ypad10/property
-property name=label translatable=yes /property
+property name=label translatable=yeslt;igt;Passwords do not matchlt;/igt;/property
+property name=use_markupTrue/property
/object
packing
property name=expandTrue/property
diff --git a/glade/persistencewindow.glade b/glade/persistencewindow.glade
index 96423fc..dbd1c7c 100644
--- a/glade/persistencewindow.glade
+++ b/glade/persistencewindow.glade
@@ -301,7 +301,8 @@
property name=xalign0/property
property name=xpad10/property
property name=ypad10/property
-property name=label translatable=yes /property
+property name=label translatable=yeslt;igt;Wrong passphrase. Please try again.lt;/igt;/property
+property name=use_markupTrue/property
/object
packing
property name=expandTrue/property
--
1.7.2.5
From ce427d4da8eadd0928b99e535e30551108c930ce Mon Sep 17 00:00:00 2001
From: Tails developers ta...@boum.org
Date: Mon, 6 May 2013 11:23:03 +
Subject: [PATCH 2/3] Separate forward and login buttons and make them translatable
---
GdmGreeter/persistencewindow.py | 18 +-
glade/persistencewindow.glade | 19 +--
2 files changed, 26 insertions(+), 11 deletions(-)
diff --git a/GdmGreeter/persistencewindow.py b/GdmGreeter/persistencewindow.py
index 3db106a..657544f 100644
--- a/GdmGreeter/persistencewindow.py
+++ b/GdmGreeter/persistencewindow.py
@@ -21,8 +21,7 @@
-import logging, gtk, gettext, os
-_ = gettext.gettext
+import logging, gtk, os
import GdmGreeter
from GdmGreeter.language import TranslatableWindow
@@ -49,8 +48,7 @@ class PersistenceWindow(TranslatableWindow):
self.btn_moreoptions_yes = builder.get_object(moreoptions_yes_button)
self.btn_moreoptions_no = builder.get_object(moreoptions_no_button)
self.btn_login = builder.get_object(login_button)
-self.img_login =
