Re: [Tails-dev] Please review'n'merge feature/monkeysign
On Wed, Dec 18, 2013 at 12:26:32AM +0100, intrigeri wrote: berta...@ptitcanardnoir.org wrote (17 Dec 2013 22:29:20 GMT) : I've just reported this problem upstream. Being the one that raised the issue. I could have done that myself after our discussion. Credits, etc... I felt it was my responsibility to follow-up on the problems that go with a branch I've submitted. I'm sorry. Ah, my bad, didn't think about it that way, and it makes sense. Nevermind then. This confirms that we really need to get you a spare laptop for testing :p Hmm, well, make it two then, as my computer actually don't have a camera. :) I'll think about it, and if I don't find a way to test it, I'll ask for someone else to take over. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support for modern Vagrant
Hi, David Wolinsky wrote (18 Dec 2013 01:12:05 GMT) : Yeah, without inserting the keys it fails at apt-get -y install apt-cacher-ng in setup-tails-builder Ah, I see: I guess our basebox is getting old, and likely did not get the latest debian-archive-keyring update [1] that is needed to validate current Debian unstable repos. So, what we need to do to fix the root of the problem is to build an updated Vagrant basebox that includes the latest debian-archive-keyring. Reported as #6516. [1] http://ftp-master.metadata.debian.org/changelogs//main/d/debian-archive-keyring/debian-archive-keyring_2010.08.28+squeeze1_changelog 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] Persistent guard nodes on DVD boot
Robert Ransom: On 12/3/13, Carribbean Rob carryb...@riseup.net wrote: Hi, I believe that one of the drawbacks of Tails, when compared to other privacy focused distributions, is that the entry nodes change each boot when using a DVD. This is fine if the IP address that someone is connecting to Tor from also changes but in some scenarios this may not be the case. As the Tor Blog outlines in a recent post, changing entry nodes each boot can become a security risk over time [1]. I have been thinking about how to improve this situation while also preserving the non-persistent nature of booting Tails from a DVD where keeping /var/lib/tor across boots is difficult. Would it be possible to choose entry guards on the first boot and then use the IP of the guard as a seed for a 4 word passphrase, maybe XOR'd with a PIN to increase the search space? Given the small number of entry guards it would be trivial to later match the supplied four word passphrase with the correct bridge/PIN on the next boot. This way you would be able to choose the same entry guard each boot until it goes down. When the entry guard goes down, a new 4 word passphrase is generated and recorded by the user. If three entry guards are used then a 12 word phrase would be output where each four words would represent a bridge. Nice try, but (a) that doesn't store enough information about each guard, and (b) users will not cooperate. See https://bugs.torproject.org/2653 for the real fix. Hi Robert, I didn't find your reply very encouraging :( Finding a good way to support entry guards in Tails is a tricky issue. Unfortunately, this goal is too far on our roadmap [1] for the core devs to have time to really think about it. So we shouldn't refrain people from brainstorming about it and I'd like to encourage new contributors into our discussions. The debate on the Tor trac is interesting but I don't think you can pretend this is as being the real fix, it looks more like an ongoing collective debate to me. And having this debate on the Tails channels really makes sense. [1] https://labs.riseup.net/code/projects/tails/roadmap signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
Andreas Kuckartz: I installed Tails 0.22 using Tails Installer. But the USB stick does not boot. It I never used the Tails Installer of older Tails versions. Booting is no problem from the same USB stick when Tails is installed on it using the isohybrid+dd method of installation. Hi Andreas, Unfortunately we can't help you, because your description doesn't include enough information. Please read our bug reporting instructions at https://tails.boum.org/doc/first_steps/bug_reporting/tails_does_not_start/ And also, could you move this thread to our support channels? Either tails-supp...@boum.org for a public list otherwise ta...@boum.org is fine as well. That way we reduce the noise on tails-dev@boum.org which is meant for development issues. signature.asc Description: OpenPGP digital signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Last steps toward enabling incremental upgrades by default [
On Tue, Dec 17, 2013 at 08:36:29PM +0100, intrigeri wrote: Hi, berta...@ptitcanardnoir.org wrote (17 Dec 2013 18:10:18 GMT) : Congrats, I'm excited to see this coming in the wild! :) ... and I'm scared to discover the remaining bugs we've missed :] Next steps: * bertagaz reviews feature/incremental-upgrades-integration (but does not merge it yet) and hopefully ACK's it; ETA? I'll try to do that tomorrow if I have remaining time after the other review'n'merge I have planned to do, but that sounds unlikely, so if not I should be able to do that before the end of the week. I wanted to test this incremental upgrade feature since a while anyway. IMHO this review (without merge) is higher-priority than the other ones you have on your plate (namely: #6477 and #6496). Ok, then I did test it the way you proposed, and it works great. So I've marked the ticket QA-Pass, and assigned it to sajolida. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
sajol...@pimienta.org: Andreas Kuckartz: I installed Tails 0.22 using Tails Installer. But the USB stick does not boot. It I never used the Tails Installer of older Tails versions. Booting is no problem from the same USB stick when Tails is installed on it using the isohybrid+dd method of installation. Hi Andreas, Unfortunately we can't help you, because your description doesn't include enough information. Please read our bug reporting instructions at https://tails.boum.org/doc/first_steps/bug_reporting/tails_does_not_start/ And also, could you move this thread to our support channels? Either tails-supp...@boum.org for a public list otherwise ta...@boum.org is fine as well. That way we reduce the noise on tails-dev@boum.org which is meant for development issues. Thanks, but I do not need support for that problem. I only tried to use the Tails Installer to be able to test the incremental update feature which seems to require that Tails is installed using the Tails Installer: https://tails.boum.org/news/test_incremental_upgrades/ I will wait until incremental updates can be used when Tails was installed using the isohybrid+dd method of installation. Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
Andreas Kuckartz wrote (18 Dec 2013 14:13:21 GMT) : I will wait until incremental updates can be used when Tails was installed using the isohybrid+dd method of installation. I doubt this is ever supported. 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] Installed Tails using Tails Installer: USB stick does not boot
intrigeri: Andreas Kuckartz wrote (18 Dec 2013 14:13:21 GMT) : I will wait until incremental updates can be used when Tails was installed using the isohybrid+dd method of installation. I doubt this is ever supported. I originally had assumed that the result does not in any way depend on the used installation method. Why is there a difference between the two methods? And what is the difference? Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support for modern Vagrant
Done and done https://labs.riseup.net/code/issues/6514 On Tue, Dec 17, 2013 at 3:13 PM, intrigeri intrig...@boum.org wrote: David Wolinsky wrote (17 Dec 2013 19:47:13 GMT) : Ah, I'll fix this and make another patch later today. Great! This is now tracked as https://labs.riseup.net/code/issues/6514. If you have no account on our Redmine yet, perhaps it's time to get one :) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support for modern Vagrant
What's your preferred method? Shall we just hack the keys into the git repo for now until the maintainer of the box has a chance to update it? As soon as we can get rid of these issues, I'm going to dive into getting Tails working with KVM and LXC per our WiNoN discussion. David On Wed, Dec 18, 2013 at 6:46 AM, intrigeri intrig...@boum.org wrote: Hi, David Wolinsky wrote (18 Dec 2013 01:12:05 GMT) : Yeah, without inserting the keys it fails at apt-get -y install apt-cacher-ng in setup-tails-builder Ah, I see: I guess our basebox is getting old, and likely did not get the latest debian-archive-keyring update [1] that is needed to validate current Debian unstable repos. So, what we need to do to fix the root of the problem is to build an updated Vagrant basebox that includes the latest debian-archive-keyring. Reported as #6516. [1] http://ftp-master.metadata.debian.org/changelogs//main/d/debian-archive-keyring/debian-archive-keyring_2010.08.28+squeeze1_changelog 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 mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Support for modern Vagrant
On 12/18/2013 05:22 PM, David Wolinsky wrote: What's your preferred method? Shall we just hack the keys into the git repo for now until the maintainer of the box has a chance to update it? I think that you can also build a box using the definitions folder. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Installed Tails using Tails Installer: USB stick does not boot
Hi, Andreas Kuckartz wrote (18 Dec 2013 15:54:43 GMT) : intrigeri: Andreas Kuckartz wrote (18 Dec 2013 14:13:21 GMT) : I will wait until incremental updates can be used when Tails was installed using the isohybrid+dd method of installation. I doubt this is ever supported. I originally had assumed that the result does not in any way depend on the used installation method. Why is there a difference between the two methods? And what is the difference? First, IIRC the isohybrid+dd method does not create a writable filesystem with empty space, so we can't easily install the IUK anywhere. Second, we simply don't have the resources to support every possible installation method for every Tails feature. So, some features are only supported for the best supported installation method, that is, when using the Tails Installer. Please don't Cc me, I read the list. 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] Support for modern Vagrant
Hi, David Wolinsky wrote (18 Dec 2013 17:22:07 GMT) : What's your preferred method? Shall we just hack the keys into the git repo for now until the maintainer of the box has a chance to update it? Unfortunately, the box currently has no maintainer. If someone gives me precise instructions, that work on current Debian unstable, to build an up-to-date one, then I'm happy to upload it. Any taker? Otherwise, yes, I guess it might be an acceptable temporary workaround to add the needed keys to our Git repositories. I'm not utterly enthusiastic, but oh well, getting this working, somehow, is important. Hopefully all this will get a lot nicer and simpler once we move to vagrant-libvirt (#6354), currently in initial funny work^W^WPoC done, less-fun polishing is needed to make it production-ready state. As soon as we can get rid of these issues, I'm going to dive into getting Tails working with KVM and LXC per our WiNoN discussion. Awesome! :) 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] Support for modern Vagrant
David Wolinsky wrote (18 Dec 2013 17:19:53 GMT) : Done and done https://labs.riseup.net/code/issues/6514 Thank you! This patch does not apply on current Tails Git, so I guess it depends on your other patch (#6221) to be applied first. I've marked it as such in Redmine, feel free to correct me. Please reassign to me for review once #6221 is sorted out. Oh, by the way, do you need a Tails Git repository, so that you can submit branches instead of attached patches in the future? We can easily provide this. If you wish so, please send an OpenPGP signed request to tails-sysadm...@boum.org, with your SSH public key attached, stating what repository you need. 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] Regarding software change
Hello Dev. First, very nice job you are doing! I do have 2 things that I believe would be wise to change. First up is the ecryptfs-utils - this is a very solid encryption tool that I think would be very handy to ship with your live cd. Next up is the video editor. I think it would be wise to change the pitivi video editor with the kdenlive instead. I know this would require more disk space, but kdenlive has become a very stable a feature rich editor. I have tried pitivi, and it has a nasty habit to crash almost instantly. Hope you can use my inputs. Best regards ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Persistence: display nicer paths
Hi,
Attached the second version, my comments:
+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;
This naming scheme is not correct for all kinds of supported devices,
e.g. SD cards plugged into a reader wired via SDIO. See commit
83637f4e for details. Doesn't $self-persistence_partition have
a DeviceFile property that we could use instead of manually appending
the partition number this way? If it has, let's simply use it. Else,
using the info from commit 83637f4e should be good enough.
Ok in this version of tails-persistence was possible to use simply
DeviceFilePresentation :)
Cheers,
Andres
From 66e863907f7ecb4e02823d3731cc6bd53eb8c7ed Mon Sep 17 00:00:00 2001
From: kurono andres.go...@cern.ch
Date: Wed, 18 Dec 2013 23:10:04 +0100
Subject: [PATCH] persistence: display nicer paths
---
lib/Tails/Persistence/Setup.pm |9 +
lib/Tails/Persistence/Step/Configure.pm |4 ++--
lib/Tails/Persistence/Step/Delete.pm|5 +++--
3 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/lib/Tails/Persistence/Setup.pm b/lib/Tails/Persistence/Setup.pm
index 431e71a..1944737 100644
--- a/lib/Tails/Persistence/Setup.pm
+++ b/lib/Tails/Persistence/Setup.pm
@@ -102,6 +102,7 @@ has 'main_window' =
has $_ = lazy_build ro Str
for (qw{override_liveos_mountpoint override_boot_device override_system_partition});
+has 'persistence_partition_device_file'= lazy_build ro Str, metaclass = 'NoGetopt';
has 'persistence_partition_size' = lazy_build ro Int, metaclass = 'NoGetopt';
has 'persistence_is_enabled' = lazy_build ro Bool, metaclass = 'NoGetopt';
has 'persistence_is_read_write' = lazy_build ro Bool, metaclass = 'NoGetopt';
@@ -270,6 +271,12 @@ sub _build_size_of_free_space {
);
}
+sub _build_persistence_partition_device_file {
+my $self = shift;
+
+$self-get_device_property($self-persistence_partition, 'DeviceFilePresentation');
+}
+
sub _build_persistence_partition_size {
my $self = shift;
@@ -695,6 +702,7 @@ sub step_object_from_name {
$self-delete_persistence_partition({ @_ })
},
persistence_partition = $self-persistence_partition,
+persistence_partition_device_file = $self-persistence_partition_device_file,
persistence_partition_size = $self-persistence_partition_size,
);
}
@@ -705,6 +713,7 @@ sub step_object_from_name {
},
configuration = $self-configuration,
persistence_partition = $self-persistence_partition,
+persistence_partition_device_file = $self-persistence_partition_device_file,
persistence_partition_size = $self-persistence_partition_size,
);
}
diff --git a/lib/Tails/Persistence/Step/Configure.pm b/lib/Tails/Persistence/Step/Configure.pm
index 9f3d4a0..e2c33cf 100644
--- a/lib/Tails/Persistence/Step/Configure.pm
+++ b/lib/Tails/Persistence/Step/Configure.pm
@@ -31,7 +31,7 @@ textdomain(tails-persistence-setup);
has 'configuration' = required ro 'Tails::Persistence::Configuration';
-has 'persistence_partition' = required ro Str;
+has 'persistence_partition_device_file' = required ro Str;
has 'persistence_partition_size' = required ro Int;
has 'list_box' = lazy_build ro 'Gtk2::VBox';
@@ -66,7 +66,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-persistence_partition_device_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 747dadd..0b5857a 100644
--- a/lib/Tails/Persistence/Step/Delete.pm
+++ b/lib/Tails/Persistence/Step/Delete.pm
@@ -25,10 +25,11 @@ textdomain(tails-persistence-setup);
=cut
-has 'persistence_partition' = required ro Str;
+has 'persistence_partition_device_file' = required ro Str;
has 'persistence_partition_size' = required ro Int;
has 'warning_icon' = lazy_build rw 'Gtk2::Image';
+
=head1 CONSTRUCTORS
=cut
@@ -45,7 +46,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-persistence_partition_device_file,
Re: [Tails-dev] Two new easy liveusb-creator tasks [Was: Please review'n'merge liveusb-creator's bugfix/dont-fail-upgrade-if-tmp-dir-exists-on-destination]
Hi, OK that's another bug: if not self.live.existing_live_os, it tries to copy a new liveos without confirmation and without removing tmp. FTR, the two bugs discovered when testing this patch are #6437 and #6438, that should be easily fixed by anyone who has touched liveusb-creator's codebase before. Andres, maybe? Ok I'll have a look of it. Cheers, Andres ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Two new easy liveusb-creator tasks [Was: Please review'n'merge liveusb-creator's bugfix/dont-fail-upgrade-if-tmp-dir-exists-on-destination]
Andres Gomez Ramirez wrote (18 Dec 2013 22:31:27 GMT) : Ok I'll have a look of it. Awesome! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Using VMs in Tails
Per the thread on the Tor tracker ( https://trac.torproject.org/projects/tor/ticket/7681), I want to start working on integrating the of Pseudonymity as defined by WiNoN into Tails. Namely, users run multiple, independent VMs connected to independent paths through the Tor network in order to wear multiple hats. A user accessing IRC and GMail under two different contexts would do so in two different VMs. There are other benefits of using VMs as the Whonix folks have recognized. Namely, that information about the host cannot (easily) leak into the guest and vice-versa. To do this I propose the following: - In the host, we run redsocks (http://darkk.net.ru/redsocks/), this will pick up traffic from the VMs and redirect it to Tor. Currently there exists no package for redsocks in Squeeze, should we check to see if the Wheezy package works or just build our own Redsocks package? - Install the necessary software for both LXC and KVM - Give amnesia the right sudo abilities to start LXC and KVM - Add start LXC Pseudonym and KVM Pseudonym to the desktop - Upon starting a Pseudonym, we'll add a Tap device and connect it to a bridge, where redsocks will pick up the traffic. For each pseudonym, we'll run a unique redsocks instance and start a new Tor proxy socket. - We can either a pseudonym watcher to clean up state or just run the pseudonym in a script, blocking on the VM execution. When the VM has been closed, it is automatically cleaned up. - Use IP Tables to enforce communication between the pseudonyms and Tor In this instance, each pseudonym will have a unique IP address, but it will only be able to talk to Tor running via the bridge and not other pseudonyms. Call this round 1, and we'll add more details as we discuss. Cheeers, David ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
