Re: [Tails-dev] Meeting: our Tails/Jessie progress and plans
On 01/12/14 20:15, intrigeri wrote: Hi, so, we wanted to have that meeting in the 2nd half of September, and then we failed. Anyway, since then, we've made good progress, and things are starting to look quite good! I think it's time to meet, talk and adjust our plans. I hereby propose a dedicated meeting at 4pm CET on December 18, 19 or 20. I do not expect to make it any of these dates. What about December 15, 16, or 17? Worst case, if your proposed dates are the only ones that work for you, I may be able to make it on the 18th, but then it has to be earlier, maybe at 12:00 CET. What do you think? Cheers! ___ 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.
Re: [Tails-dev] Release schedule for Tails 1.2.1
Hi, Mozilla broke TBB's deterministic build setup with ESR 33.3.0, and while we may have linux32 builds of TBB 4.0.2 ready later today, they'll be without QA. Therefore I think we should delay Tails 1.2.1 with one day, so we test and release on 2014-12-03. Any objections to this new plan? As I said earlier in this thread I won't be available tomorrow. Good luck! Cheers ___ 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.
Re: [Tails-dev] Meeting: our Tails/Jessie progress and plans
Hi, anonym wrote (02 Dec 2014 10:22:12 GMT) : On 01/12/14 20:15, intrigeri wrote: I hereby propose a dedicated meeting at 4pm CET on December 18, 19 or 20. I do not expect to make it any of these dates. What about December 15, 16, or 17? It's less practical for me (and I'll be more tired / less focussed, so it's good if someone else than me prepares the discussion and hosts it), but I can do it on the 15th or 16th, starting at 7pm. Cheers! -- intrigeri ___ 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.
Re: [Tails-dev] vpwned + greeter
On 03/11/14 23:42, Jurre van Bergen wrote: On 11/02/2014 12:48 AM, intrigeri wrote: Hi, Jacob Appelbaum wrote (24 Jul 2014 01:16:26 GMT) : I've waited a while for folks to read it and I think at this point, we're at year two or so of waiting. It seems like the easy thing is to simply give up and advocate for a fix with a simple patch. I have to admit I'm still affected by my vague memories of what I felt while reasoning about it two years ago, that is not being convinced that the attacks described in the paper were part of what Tails is seriously trying to protect against (as in: if an attacker can do that, then they possibly have other, and maybe easier ways to do it even if we kill access to RFC1918 addresses). Unfortunately, I've let it in the shape of very incomplete and not publishable notes back then, never came back to it, and have been feeling bad about it ever since. Yay. I've sent these notes to Jurre, who's recently volunteered to think this through. I'd love to see this happen anyway, but after two years of waiting for it, maybe we should stop blocking on it and move on. (Yes, it can take me a looong time to change my mind. You've not seen it all yet.) I've thought it true, but i've been lazy and not sending out my thoughts. Luckily, it seems that we had similar thoughts, yay. I'm not an UX person but I see the following solution(s) living next to each other if needed. Coming from a security point of view, I believe it's better to enable things than to disable things. Most of our users might not understand the risks associated to attacks described in vpwned and dma capable devices. We therefor, shouldn't make them vulnerable by default but rather by choice and document in a clear way what the risks associated to it are. I'd also rather not advocate for a way to enable through out a session, it's like having intercourse and deciding, gosh, we're ready to go but we're out of condoms, but whatever, just this one time. I think you fail to explain why having the decision during the session makes the situation worse, and I do not think your metaphor is particularly appropriate (and by that I do not mean that I think it's immoral :). Damn language ambiguities!): the safer options would be the default, so it's like being born with a condom that may be temporarily removed. Furthermore, if the decision can be made at Greeter time only, that means that the condom suddenly loses the ability to be removed as soon as sex has been initiated. This is pretty weird, and at least I cannot relate to the metaphor any more, so I'm dropping it. :) The implications might be for a lifetime. The same goes for rebooting and setting picking the less safe option when the user needs that. I don't see why allowing post-session decisions changes anything w.r.t. exposure (except Con 1, see below). I think there arguments both for and against allowing post-session security decisions (and I'm trying to be a bit more general here): * Pro 1: if people are frequently frustrated by some security decision, they will train a tendency to always pick the less secure option without thinking. Having to reboot to redo the decision is frustrating. Allowing it to happen during the session removes that frustration, and may make the user more happy to pick the default, more secure option. * Pro 2: with post-session decisions, the insecure option can be enabled temporarily, only when needed, reducing the duration of exposure. At least it is much less frustrating compared to yet another reboot. (This doesn't make sense in some cases, like compromised hardware with DMA access, which presumably would run it's attack immediately.) * Con 1: if the Live user account is compromised during the session, the attacker can make these decisions, potentially deepening the compromise further. * Con 2: at least some things are much harder to implement in such a dynamic way (allowing/disallowing LAN ports is easy, though). I'm sure there are more pros and cons, and I think we need to identify these and weigh them against each other. As for the feature in question, I think Pro 1 and Pro 2 are individually stronger than Con 1, and Con 2 doesn't even apply. 1) When I boot Tails, i'm presented with an option to allow local traffic or not. 2) When I boot Tails, i'm presented with an option to allow certain local traffic like SSH and printing and the rest not. Are these two distinct options? If so, what's the difference? 3) When I boot Tails, i'm presented with an option to be able to login to a captive portal, only this IP is whitelisted on the firewall rules and the rest is blocked. Luckily, this is not needed. Captive portals are dealt with via the Unsafe Browser, which still should have unrestricted access to the network. Or am I missing some point why the Unsafe Browser should also be affected by the LAN access blocking? I think my aim with providing these options is that, when you boot a computer,
Re: [Tails-dev] Meeting: our Tails/Jessie progress and plans
Hi, I think it's time to meet, talk and adjust our plans. I hereby propose a dedicated meeting at 4pm CET on December 18, 19 or 20. I do not expect to make it any of these dates. What about December 15, 16, or 17? Worst case, if your proposed dates are the only ones that work for you, I may be able to make it on the 18th, but then it has to be earlier, maybe at 12:00 CET. I'm interested to attend. I'm available the 15th, 16th and 18th. Cheers ___ 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.
Re: [Tails-dev] Windows camouflage for Jessie/GNOME shell
Hi, are there any statistics/experciences from users that actually use the camouflage mode? Cheers, spriver Am 2014-12-02 15:24, schrieb Alan: Hi, Let's start thinking about Windows camouflage for Tails Jessie/GNOME shell (https://labs.riseup.net/code/issues/8064) Do we still want to provide Windows Camouflage? How much energy do we want to put in it and who wants to participate? If we want to keep shipping a windows camouflage for Tails Jessie, I propose we stay on windows 8, which is still the current Windows version. It means we could keep (most of) the GTK+ and icon theme as a basis and only replace the gnome-panel theme by a GNOME Shell thing. About implementation : - I think having a desktop looking like windows 8 desktop shouldn't be too hard. I didn't find such a pre-made theme. I's probably about writing a custom shell extension, inspired by GNOME's classic set of extensions; - mimic windows 8 metro interface in GNOME Shell activity view looks doable but harder for me. I didn't find anything on the web. I'm up for participating to the effort if we collectively think it makes sense. However I'm not sure that I want to handle it alone. Cheers ___ 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 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] Fw: [Officesecurity] LibreOffice 3.5 segfaults
Hi ! a user report a crash of LibreOffice when opening one of two particular files to their team, they reply that : These are crashes in libwps not in LibreOffice. LibreOffice is just linked to libwps. You should report this particular problem to your distro, they probably need to either upgrade libwps (and the ridiculously old version of LibreOffice) or backport whatever fix exists in the more recent libwps which makes that version not crash in the same place as the old version. the kernel logs: Nov 28 10:56:35 localhost kernel: [ 1468.508145] soffice.bin[12734]: segfault at 75 ip edb0f456 sp ffd8cac0 error 4 in libwps-0.2.so.2.0.7[edabe000+69000] Nov 28 10:56:48 localhost kernel: [ 1481.259524] soffice.bin[12758]: segfault at ff356ffc ip edb28267 sp ff357000 error 6 in libwps-0.2.so.2.0.7[edad9000+69000] I reproduced that bug, and the user said that he partially reproduced it with libwps-0.2.9 on FreeBSD (one file crashes, the other don't) cheers. (the user agreed that I send those files on a public list) id:15,src:00,op:flip1,pos:48,+cov Description: Binary data id:51,src:00,op:flip1,pos:5832 Description: Binary data signature.asc Description: PGP signature ___ 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.
Re: [Tails-dev] [review'n'merge: 1.2.2] bugfix/7644-remove-mounted-image-from-vagrant-build-box
On Mon, 1 Dec 2014 14:29:38 + (UTC) anonym ano...@riseup.net wrote: Any takers? KillYourTV? This branch worked fine. I wholeheartedly agree with merging. -- GPG ID: 0x5BF72F42D0952C5A Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A pgpxoQjlt0fJo.pgp Description: OpenPGP digital signature ___ 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.
Re: [Tails-dev] Building with Vagrant (doc update)
On Mon, 1 Dec 2014 17:38:54 + (UTC) intrigeri intrig...@boum.org wrote: hi, anonym wrote (01 Dec 2014 12:35:46 GMT) : I think this is better than the current unauthenticated workaround, so I pushed new instructions live. I also pushed some other improvements: Great! I think you messed up the EOF syntax, though (hmm, untested instructions? ;) Should be fixed with commit f231fb1fd. A problem visible with `apt-cache policy vagrant` *** 1.4.3+dfsg1-3 0 1 http://snapshot.debian.org/archive/debian/20141010T042049Z/ unstable/main amd64 Packages 100 /var/lib/dpkg/status N: Ignoring file 'vagrant-1.4.3' in directory '/etc/apt/preferences.d/' as it has an invalid filename extension Perhaps apply the following? diff --git a/wiki/src/contribute/build.mdwn b/wiki/src/contribute/build.mdwn index b3affe8..a042965 100644 --- a/wiki/src/contribute/build.mdwn +++ b/wiki/src/contribute/build.mdwn @@ -73,7 +73,7 @@ At the moment Tails relies on a version of Vagrant (the 1.4.x series) that is not packaged in Debian any more. Here's a workaround for both Debian Wheezy and Jessie: -sudo tee /etc/apt/preferences.d/vagrant-1.4.3 EOF +sudo tee /etc/apt/preferences.d/vagrant-143 EOF Package: vagrant Pin: version 1.4.3+dfsg1-3 Pin-Priority: 550 pgpbTa3nakCeu.pgp Description: OpenPGP digital signature ___ 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] Call for translations: Tails 1.2.1 release notes and 1.2 security announce
Hi, translating team! Please translate the following PO files in the 'stable' branch: * wiki/src/news/version_1.2.1.*.po * wiki/src/security/Numerous_security_holes_in_1.2.*.po Cheers! ___ 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] Fwd: Call for translations: Tails 1.2.1 release notes and 1.2 security announce
[resending to the appropriate list. please drop -dev@ from the Cc list when replying.] ---BeginMessage--- Hi, translating team! Please translate the following PO files in the 'stable' branch: * wiki/src/news/version_1.2.1.*.po * wiki/src/security/Numerous_security_holes_in_1.2.*.po Cheers! ___ 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. ---End Message--- -- intrigeri ___ 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.
Re: [Tails-dev] GNOME safety list report
Hi, Alan wrote (02 Dec 2014 14:17:51 GMT) : Here is a quick summary of what happened on GNOME saftey list. Thanks a lot! * There was a thread about proposals for OPW, including : [...] Were any of these projects accepted in the end? * There was an announce that GNOME Keysign, a tool which helps to sign OpenPGP keys was released Anyone wants to file a RFP bug about it? (x-debbugs-cc: pkg-gnome-maintain...@lists.alioth.debian.org) Cheers, -- intrigeri ___ 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.
Re: [Tails-dev] Building with Vagrant (doc update)
hi, Kill Your TV wrote (02 Dec 2014 20:49:59 GMT) : Perhaps apply the following? [...] -sudo tee /etc/apt/preferences.d/vagrant-1.4.3 EOF +sudo tee /etc/apt/preferences.d/vagrant-143 EOF I would even drop the version number from the filename: it'll only be more painful e.g. if we want to update this piece of doc to, say, Vagrant 1.4.5 (we would need to tell people to remove vagrant-$VERSION, and then create another file, or something). I propose /etc/apt/preferences.d/tails-build-vagrant. Cheers! ___ 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.
Re: [Tails-dev] Building with Vagrant (doc update)
On Tue, 2 Dec 2014 23:58:02 + (UTC) intrigeri intrig...@boum.org wrote: I propose /etc/apt/preferences.d/tails-build-vagrant. That works for me (of course). :) pgpE1JIeVisFz.pgp Description: OpenPGP digital signature ___ 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.
