[Tails-dev] Made New Identity work again, please review

2014-02-28 Thread winterfairy
 +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

2014-02-27 Thread winterfairy
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

2014-02-21 Thread winterfairy
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

2014-02-20 Thread winterfairy
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

2014-02-20 Thread winterfairy
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

2014-02-14 Thread winterfairy
 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

2014-02-13 Thread winterfairy
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

2014-02-11 Thread winterfairy
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

2014-02-11 Thread winterfairy
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

2013-12-11 Thread winterfairy
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

2013-12-09 Thread winterfairy
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

2013-12-08 Thread winterfairy
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

2013-12-07 Thread winterfairy
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

2013-12-06 Thread winterfairy
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

2013-12-04 Thread winterfairy
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]

2013-12-02 Thread winterfairy
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

2013-12-02 Thread winterfairy
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?]

2013-12-01 Thread winterfairy
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

2013-12-01 Thread winterfairy
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?

2013-11-30 Thread winterfairy
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

2013-11-30 Thread winterfairy
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

2013-11-29 Thread winterfairy
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

2013-11-27 Thread winterfairy
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?

2013-11-27 Thread winterfairy
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

2013-11-24 Thread winterfairy
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

2013-11-22 Thread winterfairy
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?

2013-11-22 Thread winterfairy
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

2013-11-21 Thread winterfairy
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

2013-11-21 Thread winterfairy
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

2013-11-16 Thread winterfairy
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

2013-11-15 Thread winterfairy
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

2013-11-07 Thread winterfairy
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

2013-11-07 Thread winterfairy
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

2013-11-06 Thread winterfairy
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?

2013-11-05 Thread winterfairy
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

2013-11-04 Thread winterfairy
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?

2013-11-04 Thread winterfairy
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

2013-11-02 Thread winterfairy
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

2013-11-02 Thread winterfairy
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

2013-11-01 Thread winterfairy
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?

2013-09-21 Thread winterfairy
 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?

2013-08-25 Thread winterfairy
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

2013-06-24 Thread winterfairy
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

2013-06-24 Thread winterfairy
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

2013-06-24 Thread winterfairy
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

2013-05-28 Thread winterfairy
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

2013-05-25 Thread winterfairy
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

2013-05-13 Thread winterfairy
 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

2013-05-06 Thread winterfairy
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 =