[Tails-dev] GNOME safety and privacy team
https://people.gnome.org/~federico/news-2014-08.html#the-safety-and-privacy-team They speak about Tails, they want input and seem willing to improve things :) Cheers, BitingBird ___ 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] Broadcom Wireless Drivers
[Update] To make my life easier I'm trying to get some of this done in a virtual machine, then move over to the actual live CD after I know I can do it. I'm still working on getting the Broadcom STA Linux drivers working with Tails 1.1.1. I downloaded the driver from http://www.broadcom.com/support/802.11/linux_sta.php and extracted it to my home directory. sudo apt-get update sudo apt-get install make cd ~ sudo make KBUILD_NOPEDANTIC=1 make -C /lib/modules/`uname -r`/build M=`pwd` make: *** /lib/modules/3.14-2-amd64/build: No such file or directory. Stop. make: *** [all] Error 2 If I understand that correctly, the Makefile is directing make to /lib/modules/3.14-2-amd64/build, but build doesnt exist. If I create build it enters the directory then leaves it stating that nothing is there to make (which makes sense). Am I missing something? What should be in build, or what is the Makefile trying to make? ~xian ___ 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 and privacy team
Hi, BitingBird wrote (24 Sep 2014 14:47:54 GMT) : https://people.gnome.org/~federico/news-2014-08.html#the-safety-and-privacy-team Thanks a lot! I think it would be good if at least one of us started to act as the contact point between GNOME and Tails. Subscribing to the desktop-devel list [1], and getting in touch with their new safety team to make it clear that we're open to collaboration, would be a good start. Anyone? Alan, maybe? [1] https://mail.gnome.org/mailman/listinfo/desktop-devel-list 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] Broadcom Wireless Drivers
Hi Kristi, On 09/24/2014 07:15 PM, Kristi Grant wrote: If I understand that correctly, the Makefile is directing make to /lib/modules/3.14-2-amd64/build, but build doesnt exist. If I create build it enters the directory then leaves it stating that nothing is there to make (which makes sense). Am I missing something? What should be in build, or what is the Makefile trying to make? Try to install the kernel headers before compiling. Cheers, Georg signature.asc 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] Document how to serve files over HTTP behind a Tor Hidden Service
Markdown file added: https://labs.riseup.net/code/issues/7879 - comments welcome. ___ 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] Broadcom Wireless Drivers
Hi, Kristi Grant wrote (24 Sep 2014 17:15:17 GMT) : To make my life easier I'm trying to get some of this done in a virtual machine, then move over to the actual live CD after I know I can do it. I'm still working on getting the Broadcom STA Linux drivers working with Tails 1.1.1. I downloaded the driver from http://www.broadcom.com/support/802.11/linux_sta.php and extracted it to my home directory. See the broadcom-sta-dkms Debian package instead, and the work that has been done in Debian to autodetect the correct drivers at boot time (which will allow us to install the broadcom-sta drivers in Tails without breaking support for currently supported hardware): https://bugs.debian.org/748679 https://bugs.debian.org/749109 This is tracked in the Tails bug tracker already: https://labs.riseup.net/code/issues/7798 So, the next thing to do is to build a Tails ISO with broadcom-sta-dkms and live-config 4.x (both pulled from sid), and see if that works. IMO, anything else is a waste of time, since it will only result in fixing the problem for one single user, whereas many users need this to work. 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] Migrating to (something closer to) the regular Tor Browser
Hi, First of all, not that I've fixed a few bugs and updated the automated test suite so it deals with the TBB migration. 21/09/14 00:51, intrigeri wrote: Hi, anonym wrote (20 Sep 2014 01:20:00 GMT) : +Explanation: Block installation of iceweasel until it has been removed from our APT repo +Package: iceweasel +Pin: origin deb.tails.boum.org +Pin-Priority: -1 I'm curious why we need that at all, and the explanation isn't very convincing: even once we remove it from our own APT repo, it will be available in the Debian ones, so I don't get it. [...] Something like: Explanation: keep our fake equivs-generated iceweasel package Package: iceweasel Pin: origin Pin-Priority: 1020 might be just enough to express exactly what we want to say (untested), in a way that would work in more situations. I tested it, and it didn't work: [...] The following NEW packages will be installed: libmozjs24d xulrunner-24.0 The following packages will be DOWNGRADED: iceweasel 0 upgraded, 2 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 21.8 MB of archives. After this operation, 56.0 MB of additional disk space will be used. E: There are problems and -y was used without --force-yes P: Begin unmounting filesystems... [...] Regarding config/chroot_local-hooks/10-tbb, a lot of the code could enjoy some refactoring. Currently, configuration, low-level processing and the high-level flow are too strongly intermingled for my taste. Could you please elaborate? I would suggest *naming* operations that are being done, [...] But oh well, it feels strange to pretend I can teach you anything wrt. software design and refactoring, you already know all this :) I misunderstood the scope of what you meant. I have started some work in this direction and will push it later just so that work doesn't block. +TBB_EXT=${TBB_INSTALL}/extensions I'm curious why we need to put extensions in a custom place, instead of letting them live in the place as in the TBB. I.e. directly in the browser profile skeleton at /etc/icewease/profile? Well, I'd like to just be able to copy the profile skeleton when creating a new profile without wasting space (well, RAM because tmpfs) on duplicating every extension. OK, makes a lot of sense. Make it clear in a comment? (I think we should aim at the smallest possible delta with the TB here, so documenting *why* this and that bit of our delta is needed will help whenever we try to make the delta smaller in the future, and someone will be asking exactly this kind of questions :) Ok, I think I've improved it a bit now. +# We don't want tor-launcher to be part of the browser, and we need our +# patched stand-alone version any way. s/and/as/ ? Also, I suggest pointing to the parent ticket that tracks upstreaming our changes. Well, I meant it as two separate reasons for doing that. I now realize the stand-alone in the second part creates some overlap with the first part, which may cause confusion. Would removing stand-alone make it clearer? Ah, I got it. How about: We don't want tor-launcher to be part of the regular browser profile. Moreover, for the stand-alone tor-launcher we use, we need our patched version. So, the version shipped in the TB really is not useful for us. Looks better, indeed. Applied. In config/chroot_local-hooks/12-remove_unwanted_browser_searchplugins: +PLUGIN_DIR=/usr/local/lib/tor-browser/Browser/browser/searchplugins It seems that we're hard-coding the same path information in different places. How about setting TBB_INSTALL and friends in a common place, that can be sourced by all scripts that need it? Sure. I couldn't come up with a place where we already do this. Do you have any suggestion for a good location? /etc/live/config.d? I'm unsure whether we really want to export all these variables as part of the global system-wide environment. I would instead store them somewhere that can be sourced when needed. We already do similar things in auto/config (saving stuff to /etc/amnesia/) and auto/build (saving stuff to /usr/share/amnesia/build/). I think that /usr makes more sense than /etc, as what we want to save here is really static information about how/where vendor-provided software is setup in the ISO, rather than configuration = /usr/local/lib/tails-shell-library/tor-browser.sh, maybe? It might be that we need more than variables in there at some point, so bootstrapping a mini-shell-library with these doesn't seem too crazy. Agreed. This is now done. -daddr 127.0.0.1 proto tcp syn mod multiport destination-ports (9050 9061 9062 9151) { +daddr 127.0.0.1 proto tcp syn mod multiport destination-ports (9050 9061 9062 9150) { It would be nice for anyone who has custom configuration that depends on the SOCKS port to keep the 9151 we've been using until now. OTOH, maybe people
Re: [Tails-dev] Broadcom Wireless Drivers
Kristi Grant wrote (24 Sep 2014 17:48:29 GMT) : E: Package 'linux-headers-3.14-2-amd64' has no installation candidate I think it's still in Debian testing, but probably not for long. That's why we have https://labs.riseup.net/code/issues/5926 high on our todo list. ___ 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] Broadcom Wireless Drivers
intrigeri wrote (24 Sep 2014 21:24:59 GMT) : Kristi Grant wrote (24 Sep 2014 17:48:29 GMT) : E: Package 'linux-headers-3.14-2-amd64' has no installation candidate I think it's still in Debian testing, but probably not for long. That's why we have https://labs.riseup.net/code/issues/5926 high on our todo list. Oh, and I forgot: it's clear that we won't compile these modules by hand to include them in Tails, as there are better solutions. So, the part of this discussion that's about manually workarounding the current state of things on your own machine has little to do with Tails development, and is now better suited for the tails-support@ mailing-list. Please take it there if you want to continue it :) 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.
[Tails-dev] Broadcom Wireless Drivers
intrigeri, Alright, thanks. I'll bring it over to the support list. :) Kristi Grant ___ 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] Bash bug
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear Tails users, As you might have heard there is a Bash vulnerability, I have created a temporary countermeasure write-up below. Temporary countermeasure Debian has provided an updated version, we recommend you to upgrade to the latest version of Bash and this is how you do it: This is a less safe way to do it, make sure you use a trusted network and please note this change isn't persistent. 1: Set up an administrative password[1] when you boot Tails 2: Connect to the Internet (I recommend using a trusted network) 3: Run the following in a root terminal: apt-get update apt-get install bash The more experienced user way: 1: Set up an administrative password[1] when you boot Tails 2 Download the wheezy package through a separate computer and place it on the persistent volume to install before you connect to the Internet and verify checksums :) 3 If you have the `deb` run in a root terminal: dpkg -i /path/bash.deb 4: Connect to the internet [1] https://tails.boum.org/doc/first_steps/startup_options/administration_password/index.en.html -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJUI017AAoJELc5KWfqgB0Cn1IIALCob3ymEn7sWibryZ4NWF5B pDhBEp8rlGYGdIFtiOl50ywdgS1AUPlpo7+cSj/rUpEi53K1AiIt7Aw+ZBcQohW0 jI1Oluwnckc6ZVLZblLYaes6WfINC5sp6qvFknWgla8zd5kKU5VMWVHb/9JS0KL7 yMibOVDx1ib4rxSck+z7KfbTE/CF2+JCCABI7p7pmXw134BDQesPJa76ZpNwK8z5 YV0KJ+35od7pgjTe+2ihjuqdPWlu/tHl01GJmwAA9yChwUDwiE6JMMkSSVJNwaBk j1yyA91nBF1KUk9KJReAarVp3aWFgusWGjMSPj1ILfX45IqSWk4gR+HxmZOfGpE= =/JT9 -END 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] Bash bug
25/09/14 01:02, Jurre van Bergen wrote: Dear Tails users, As you might have heard there is a Bash vulnerability, I have created a temporary countermeasure write-up below. Out of curiosity, have you (or any one else for that matter) come up with a relevant exploit in Tails? I suppose I'm talking mostly about actively supported (client-oriented) use cases -- it's obvious that any one running a custom setup with a hidden service sshd with AcceptEnv, for instance, is affected. By the way, this will be fixed in the Tails 1.1.2 emergency release [1], scheduled to be released later today (Thursday, CEST). Cheers! [1] The reason for the 1.1.2 release is not the bash bug, but the Firefox bug: https://www.mozilla.org/security/announce/2014/mfsa2014-73.html ___ 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] Bash bug
Seems the Debian patch wasn't good enough, Tavis Ormandy wrote a bypass. (https://twitter.com/taviso/status/514887394294652929) Act with caution! Jurre On 09/25/2014 01:02 AM, Jurre van Bergen wrote: Dear Tails users, As you might have heard there is a Bash vulnerability, I have created a temporary countermeasure write-up below. Temporary countermeasure Debian has provided an updated version, we recommend you to upgrade to the latest version of Bash and this is how you do it: This is a less safe way to do it, make sure you use a trusted network and please note this change isn't persistent. 1: Set up an administrative password[1] when you boot Tails 2: Connect to the Internet (I recommend using a trusted network) 3: Run the following in a root terminal: apt-get update apt-get install bash The more experienced user way: 1: Set up an administrative password[1] when you boot Tails 2 Download the wheezy package through a separate computer and place it on the persistent volume to install before you connect to the Internet and verify checksums :) 3 If you have the `deb` run in a root terminal: dpkg -i /path/bash.deb 4: Connect to the internet [1] https://tails.boum.org/doc/first_steps/startup_options/administration_password/index.en.html ___ 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.
Re: [Tails-dev] Bash bug
On 9/24/14, anonym ano...@riseup.net wrote: 25/09/14 01:02, Jurre van Bergen wrote: Dear Tails users, As you might have heard there is a Bash vulnerability, I have created a temporary countermeasure write-up below. Out of curiosity, have you (or any one else for that matter) come up with a relevant exploit in Tails? I suppose I'm talking mostly about actively supported (client-oriented) use cases -- it's obvious that any one running a custom setup with a hidden service sshd with AcceptEnv, for instance, is affected. By the way, this will be fixed in the Tails 1.1.2 emergency release [1], scheduled to be released later today (Thursday, CEST). Cheers! [1] The reason for the 1.1.2 release is not the bash bug, but the Firefox bug: https://www.mozilla.org/security/announce/2014/mfsa2014-73.html By my count we'd want to ship an update to Firefox (libnss), bash (dhclient? what else?) and apt (the http parser buffer overflow). Any other critical bugs that were disclosed in the last few hours? :) All the best, Jacob ___ 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.