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]
service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is using bits of my packaging. woot. http://ftp-master.metadata.debian.org/changelogs//main/s/service-wrapper-java/service-wrapper-java_3.5.22-1_changelog signature.asc Description: PGP signature ___ 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:50:09 + (UTC)
intrigeri wrote:
> 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)
>
Yeah that might be better. I can do the improvement 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 ;)
>
Heh..OK. I can change it to a list if that'd be preferred.
> * 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?.
This one should be 'OK'. That outproxy is for visiting "clearnet"
sites and those go out through Tor because of the FoxyProxy rules.
Without the FoxyProxy rules all http://* traffic would go out via I2P
with traffic to non-I2P sites being routed to a squid proxy running at
http://false.i2p.
This change is more cosmetic than anything since that
block could be removed and nothing would be functionally different for
a Tails user. The goal of this stanza/section was to remove the
false.i2p outproxy from the I2PTunnel configuration to try to prevent
end-users that are familiar with I2P from being confused by seeing a
configured outproxy in the interface.
signature.asc
Description: PGP signature
___
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 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
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
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] 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 wrote: > Hi, > > Kill Your TV wrote (21 Nov 2013 02:06:30 GMT) : > > intrigeri 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] 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] 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
[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
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 %s %s 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 %s %s 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
intrigeri wrote: > Kill Your TV wrote (21 Nov 2013 02:06:30 GMT) : >> intrigeri 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] [RFC] Design (and prototype) for MAC spoofing in Tails
anonym wrote (21 Nov 2013 05:58:37 GMT) : > For consistency I also > added similar help links for persistence and "more options" in the first > screen, although this easily can be reverted if not desired. TBH I see little use in this button: the documentation it links to only quickly mentions the list of options offered when choosing "more options", which can be discovered by trying it just as well, so IMHO this just adds clutter (big word, perhaps) to the UI, and not much value. 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]
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]
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] 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
[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] Please review'n'merge feature/linux-3.11-2 [Was: Broken build / Linux 3.11]
Hi, On Wed, 20 Nov 2013 16:36:53 +0100 intrigeri wrote: > the subject says it all. > No ticket, candidate for 0.22. Urgent, since > all builds are broken without this merge, so this stalls development. Works for me. Why is the branch called feature/linux-3.11-*2* while it actually install 3.11-*1*? Apart from that, the git log suits me. > There's a merge to do at the APT level too. > What is this (custom?) gcc-4.8 package and why is it needed? Once I understand why there is this package, I'm fine to merge it. Cheers ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] disabling MAC spoofing by default in VM's [Was: [RFC] Design (and prototype) for MAC spoofing in Tails]
Hi, (Splitting into per-topic sub-threads to make the discussion easier to follow.) anonym wrote (21 Nov 2013 05:58:37 GMT) : > As pointed out in a different part of this thread, some virtual machines > don't like MAC spoofing at all (e.g. in VirtualBox networking breaks > completely for NAT- and bridge-based adapters). Therefore I also made > T-G check if we're running in a virtual machine, and if so it changes > the default to *disable* MAC spoofing. For more info, see the blueprint, > section "MAC spoofing and virtual machine networking issues". > Furthermore, if the user checks the MAC spoofing box, a warning is > shown. The warning disappears if the box is unchecked, which is unlike > the warning shown when the admin passwords mismatch, which never removes > the warning. For greater consistency, I also made the latter warning > disappear once once changes any of the password entries, which I think > is a general improvement. I'm concerned about the impact on our test suite: it seems suboptimal to (automatically) test code paths that are different from the ones most users will go through. IIRC we're setting a kernel cmdline parameter when running the test suite, so perhaps this changing of defaults could be disabled when a testing environment is detected? (Assuming the libvirt/qemu stack we're using is not affected by the same issues as VirtualBox.) 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] [RFC] Design (and prototype) for MAC spoofing in Tails
anonym wrote (21 Nov 2013 05:58:37 GMT) : > To get something now I've implemented this in T-G's > feature/spoof-mac branch (actually in feature/spoof-mac-help, merged > into said branch). It seems you did not push all that stuff yet. 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] [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
