Re: [Tails-dev] [RFC] Design (and prototype) for MAC spoofing in Tails
Hi, anonym wrote (21 Nov 2013 05:58:37 GMT) : 04/11/13 14:49, intrigeri wrote: To end with, I notice the blueprint was not updated (modulo typos etc. I fixed) since almost a month. At some point, you'll want to make it include all the good thinking that was put into the recent discussions. Done. Great work, congrats! This blueprint will become a wonderful design document, that we can hand out to anyone wanting to audit this feature. I've pushed a few typo fixes and minor rephrasing (316f2fc). Remarks: * The plugging and plugged (of network interfaces) words are used in multiple places in a way that's not obvious without knowing the implementation details (or reading the relevant section below). * When pointing to scripts and configuration files, please use the tails_gitweb shortcut so that Luke^Wanyone can simply click on a link to read the source. * I had to re-read this sentence a few times to understand what it meant: Therefore we make an exception to have the MAC spoofing option enabled by default in Tails Greeter if it detects that Tails is running inside a virtual machine = please rephrase. * Regarding It would obviously require to drop `set -e`, because errors are indeed what could cause this to happen. -- err, well, I kinda disagree that letting errors propagate further, just so we can enjoy detecting it later, is obvious. set -e detects a given class of error conditions, great. The proposed failsafe check would detect another (probably overlapping) class of error conditions. I think that both should coexist. * Regarding Loss of hotplugged devices -- I'll do the test. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review and merge bugfix/additional-software-nitpicking
Hi, Please review and merge bugfix/additional-software-nitpicking which should close https://labs.riseup.net/code/issues/6431. Cheers ___ 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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
intrigeri: Kill Your TV wrote (21 Nov 2013 17:03:18 GMT) : service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is using bits of my packaging. woot. Congrats! I can't wait for I2P to be maintained in Debian proper... but I'm now wondering if it's gonna be appropriate for a Debian stable release ever. Is there a stable branch of I2P that could satisfy the Debian stable requirements (i.e. that would only backport important bug fixes and security fixes)? I find this most interesting as well. Is Debian policy fine with packages which likely never get into stable? (Personally, I'd be fine with a testing-only i2p package.) ___ 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 [Was: about the maintenance of I2P in Tails]
Kill Your TV wrote (21 Nov 2013 17:03:18 GMT) : service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is using bits of my packaging. woot. Congrats! I can't wait for I2P to be maintained in Debian proper... but I'm now wondering if it's gonna be appropriate for a Debian stable release ever. Is there a stable branch of I2P that could satisfy the Debian stable requirements (i.e. that would only backport important bug fixes and security fixes)? Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
adrelanos wrote (21 Nov 2013 17:46:01 GMT) : Is Debian policy fine with packages which likely never get into stable? Yes. (Personally, I'd be fine with a testing-only i2p package.) It's doable, but to prevent a package from going into stable, it must be dropped from testing at some (late) point of the freeze (generally thanks to a RC bug called Should not be part of stable or something). This implies that during the [removal from testing, stable release] time interval, we can't get official backports for the current stable release. A bit tricky (needs a careful maintainer and/or coordination with the release team), but still way better than the current state of things, if you ask me. Alternatively, another way to do it would be to 1. always keep the package out of testing (with a permanent should not migrate to testing RC bug, just like bitcoind has); 2. asking the Debian backports FTP masters for a general exception to be allowed to upload backports of the packages from unstable. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Thu, 21 Nov 2013 17:33:28 + (UTC) intrigeri intrig...@boum.org wrote: Kill Your TV wrote (21 Nov 2013 17:03:18 GMT) : service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is using bits of my packaging. woot. Congrats! I can't wait for I2P to be maintained in Debian proper... but I'm now wondering if it's gonna be appropriate for a Debian stable release ever. Is there a stable branch of I2P that could satisfy the Debian stable requirements (i.e. that would only backport important bug fixes and security fixes)? At the moment there isn't a stable/ESR-like branch. If there's an important bug that needs to be fixed right away there's a point release like the recent update from 0.9.8 - 0.9.8.1. I also don't know how Debian feels about packages that live in testing and unstable. signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Persistence: display nicer paths
Hello,
Thanks a lot!
If you feel it's ready for QA, please email the tails-dev ML about it
(that's the preferred way to submit patches and discuss them, as not
everybody is tracking Redmine that closely). Thanks in advance :)
Ok no problem, attached is the patch for Persistence: display nicer paths
feature - https://labs.riseup.net/code/issues/5311.
Cheers
Andres
From 4152d1fa8838e8e5d25df82e8213f8d433d19011 Mon Sep 17 00:00:00 2001
From: kurono andres.go...@cern.ch
Date: Wed, 20 Nov 2013 22:52:34 +0100
Subject: [PATCH] persistence: display nicer paths
---
lib/Tails/Persistence/Setup.pm | 15 +++
lib/Tails/Persistence/Step/Configure.pm |3 ++-
lib/Tails/Persistence/Step/Delete.pm|4 ++--
3 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/lib/Tails/Persistence/Setup.pm b/lib/Tails/Persistence/Setup.pm
index 6cd3997..1106646 100644
--- a/lib/Tails/Persistence/Setup.pm
+++ b/lib/Tails/Persistence/Setup.pm
@@ -97,6 +97,10 @@ has 'system_partition' =
lazy_build rw Str,
documentation = q{The UDI of the partition where Tails is installed, e.g. /org/freedesktop/UDisks/devices/sdb1.};
+has 'partition_file' =
+lazy_build rw Str,
+documentation = q{The persistent partition file, e.g. /dev/sdb1.};
+
has 'main_window' =
lazy_build ro 'Gtk2::Window',
metaclass = 'NoGetopt';
@@ -271,6 +275,15 @@ sub _build_system_partition {
);
}
+sub _build_partition_file {
+my $self = shift;
+
+my $device_file = $self-get_device_property($self-device, 'DeviceFile');
+my $partition_number = $self-get_device_property($self-persistence_partition, 'PartitionNumber');
+
+$device_file.$partition_number;
+}
+
sub _build_main_window {
my $self = shift;
my $win = Gtk2::Window-new('toplevel');
@@ -910,6 +923,7 @@ sub step_object_from_name {
},
persistence_partition = $self-persistence_partition,
persistence_partition_size = $self-persistence_partition_size,
+partition_file = $self-partition_file,
);
}
elsif ($name eq 'configure') {
@@ -920,6 +934,7 @@ sub step_object_from_name {
configuration = $self-configuration,
persistence_partition = $self-persistence_partition,
persistence_partition_size = $self-persistence_partition_size,
+partition_file = $self-partition_file,
);
}
diff --git a/lib/Tails/Persistence/Step/Configure.pm b/lib/Tails/Persistence/Step/Configure.pm
index 5d3603a..a5e0efe 100644
--- a/lib/Tails/Persistence/Step/Configure.pm
+++ b/lib/Tails/Persistence/Step/Configure.pm
@@ -32,6 +32,7 @@ has 'configuration' = required ro 'Tails::Persistence::Configuration';
has 'persistence_partition' = required ro Str;
has 'persistence_partition_size' = required ro Int;
+has 'partition_file' = required ro Str;
has 'list_box' = ro 'Gtk2::VBox', builder '_build_list_box';
@@ -60,7 +61,7 @@ sub BUILD {
$self-description-set_markup($self-encoding-decode(sprintf(
# TRANSLATORS: partition, size, device vendor, device model
gettext(q{The selected files will be stored in the encrypted partition %s (%s), on the b%s %s/b device.}),
-$self-persistence_partition,
+$self-partition_file,
format_bytes($self-persistence_partition_size, mode = iec),
$self-device_vendor,
$self-device_model
diff --git a/lib/Tails/Persistence/Step/Delete.pm b/lib/Tails/Persistence/Step/Delete.pm
index 40c72cf..81989e3 100644
--- a/lib/Tails/Persistence/Step/Delete.pm
+++ b/lib/Tails/Persistence/Step/Delete.pm
@@ -27,7 +27,7 @@ textdomain(tails-persistence-setup);
has 'persistence_partition' = required ro Str;
has 'persistence_partition_size' = required ro Int;
-
+has 'partition_file' = required ro Str;
=head1 CONSTRUCTORS
@@ -45,7 +45,7 @@ sub BUILD {
# TRANSLATORS: partition, size, device vendor, device model
$self-description-set_markup($self-encoding-decode(sprintf(
gettext(q{The persistent volume %s (%s), on the b%s %s/b device, will be deleted.}),
-$self-persistence_partition,
+$self-partition_file,
format_bytes($self-persistence_partition_size, mode = iec),
$self-device_vendor,
$self-device_model
--
1.7.9.5
___
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 [Was: about the maintenance of I2P in Tails]
On Thu, 21 Nov 2013 06:48:00 + (UTC) intrigeri intrig...@boum.org wrote: Hi, Kill Your TV wrote (21 Nov 2013 02:06:30 GMT) : intrigeri intrig...@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 :) I just pushed what's likely the last of the changes for 0.22. signature.asc Description: PGP signature ___ 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
winterfa...@riseup.net wrote (21 Nov 2013 14:57:57 GMT) : 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. 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? 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.) 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. That would work too. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] active probing vs. AdvGoalTracking [Was: [RFC] Design (and prototype) for MAC spoofing in Tails]
Hi, anonym wrote (21 Nov 2013 05:58:37 GMT) : Ah, I didn't connect the dots before. What you mean is that, with persistent NM-connections, the list of ssids/bssids/whatever probed for can be used as a fingerprint. Right. I haven't looked into NM's code yet, but I promise to do so soon, cause I certainly get your point. I've at least updated the blueprint to reflect this (see the Active probe fingerprinting section). Great. However, what do we expect here? In grand GNOME tradition, I can't imagine this is configurable right now. Worse, even if we write patches that make it so and send them upstream, I doubt we'll get it upstreamed within the next couple of *years*. From past experience, following a few feature-request *with patches* for years, these things move at glacial speed. I share similar experience, but I'd like to counterbalance it with some good experience we've had recently: the seahorse-nautilus patchset was promptly merged upstream, and IIRC it affected 3 different components of GNOME, maintained by 2 different teams. I also put some hope in the current mainstreaming of concerns on privacy and tracking topics, that might ease our task a bit (e.g. recent GNOME has a great configuration panel for privacy settings). To end with, zack has volunteered to help in the talk to other free software projects area, which could be very helpful too. I imagine we'll have to patch and build NM ourselves more or less indefinitely. I agree we would have to be prepared to this. Note that we only upgrade NM when we migrate Tails to a new version of Debian, so this adds work every two years only. And since the aim is to get this into Tails before wheezy we'll probably have to make a backport of the patches for 0.8.1. Right. Worse again, I imagine that the current Debian package maintainer of NM isn't very interested in maintaining a new patch-set for squeeze since it's soon to be EOL'd. My point is that that, unless I've missed something, the consequences of implementing this may result in a relatively significant addition to our maintenance burden (stealing precious dev time). And while I appreciate the implications of not doing this, I think we may want to consider not putting too much effort into this. Sending a patch upstream -- yes. Trying to make the Debian maintainer import a backported patch for *wheezy* builds -- if the backporting doesn't result in a complete re-write, definitely yes (I suppose this is more likely to happen than a quick upstreaming :)). Trying to get a backport into squeeze -- is it really worth it? Neither Debian oldstable nor stable get new features anyway, so the best we could hope (assuming the patch enters in upstream NM) for would be to either 1. backport the new upstream release (in wheezy-backports), which may be non-trivial (a number of other packages will need to be rebuilt against the new NM, and backports uploaded accordingly) or 2. backport a set of patches against the NM that's in Wheezy, ship a patched version in Tails, and get back to the Debian's NM once Tails is based on Jessie. I don't think #1 is worth it, and I don't know how hard #2 would be. In the end, I think we should first evaluate how hard it would be to implement what we need upstream, and then discuss this again. Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi, Kill Your TV wrote (21 Nov 2013 16:58:53 GMT) : I just pushed what's likely the last of the changes for 0.22. Looks good to me, modulo a few comments: * regarding commit 95ca91a (document the need for admin password): wouldn't this be more appropriate for the end-user documentation? (not a blocker, just something that could be improved in the future) * regarding commit c32cab5 (I2P: Document ferm exceptions): the HTML table seems a bit too much markup for me; how about just using a simple list? (not a blocker either, just nitpicking probably ;) * config/chroot_local-hooks/16-i2p_config still reads: # Remove the false.i2p outproxy from i2ptunnel # We already go out through Tor so this will never be reached anyway. sed -i '/^tunnel.0.proxyList/d' $I2P/i2ptunnel.config Is this still relevant? At least the comment isn't anymore, right? * I don't get why don't we would now want to install /usr/share/i2p/router.config with a chroot_local-includes anymore. AFAIK that would be the only occurrence thereof in the Tails build system. IMHO present and future changes to this file would be easier to follow this way, than by writing this file with a hook. Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Please review'n'merge feature/linux-3.11-2 [Was: Broken build / Linux 3.11]
Alan wrote (21 Nov 2013 09:18:07 GMT) :
Works for me.
Good.
Why is the branch called feature/linux-3.11-*2* while it actually
install 3.11-*1*?
What makes you think so? Here's what I see in the last Jenkins build
of experimental:
linux-image-3.11-2-4863.11.8-1
linux-image-3.11-2-686-pae3.11.8-1
There's a merge to do at the APT level too.
What is this (custom?) gcc-4.8 package and why is it needed?
The new version of linux-headers-* depends on gcc-4.8, because sid's
kernel is now built with that version IIRC, but in practice stuff we
care about compiles just well with the Squeeze version of GCC.
Official backports downgrade this dependency, IIRC. We've been doing
the same trick basically forever, see: we have gcc-4.{6,7} for the
same reasons already.
Once I understand why there is this package, I'm fine to merge it.
Please go ahead :)
Cheers,
--
intrigeri
| GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] 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
