Re: [Tails-dev] Tor Launcher extension [Was: Mike's March 2013]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thank you for starting this discussion! intrigeri: > Also, it would be really awesome if all major ways of using Tor > (TBB, Tails, etc.) could provide the same interface for configuring > how Tor should access the network. This would be interesting as well for system Tor users: https://trac.torproject.org/projects/tor/ticket/7197 And it would be interesting as well for Whonix. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJSZ1ZEAAoJEJwTGtNxOq7vywcP/Aq/ljeCblz4TV7eIVUYQD2m +Ud84okGaz+YPjbiXQUyTyR45Jrz7kyFNyo+7yTdLJsOUkbXAeD0G8gP4BlczYrW 0GJ/qtlxCaVYWjqsLrQkNMPFe7ZrPXueDkl/DTVKGrVq9Bthki6qoVCtdxKdfJDZ 2tH1UlHMSIBADKB/zco7QF4A6bu3pqjOv4c5BCqsAkhENXmvgEjBFkurZWxK2I88 bIIuZjbTtX/kFffmSWD5d0yaKxEZnLJuJo+NfhmXhUDkCL0Vgn79eBdETq1IkO7e aLmnCSFmd+RF5EgCTfZ56PuWuIOD3hfgGDxdwjf7IMrUaKIB1aSmLQkVv+d0UgC1 C/iPKvU2l4QqkNZllzmIOoL6uvJG2X4JPChDxtpcVOzlwXrT4qSliveMsbKXLvwF 08ITsEX3G99Ne8cI6jYY9Fzjrjeff2J1cYg3r9PNviwmnSyu3EIcbFBW7sbK4rYw mTku08tdwbcvI6pV68AHss4k8JP0UJkqoLv4mVmOh1S8f6PZJ/X02JeknDq6Xmzx TVzHg/pCANdSQx/kfTkp7+LB5gaDsgN0WgishQQWDC2R4asNqgCbjEP3m1yDUQOl uxXsOm0uOpu3hsyTg6rgPGh7XFHv+dQCDmvIg7kixWrtKH2Qj03sRLym2Po8CrK5 O0Ab8jzKjFNB77KZPa+Y =LQYu -END PGP SIGNATURE- ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bug#725779: libotr: OTR clients supporting both OTRv1 and v2 are subject to protocol downgrade attacks
On 23 oct. 2013, at 01:53, Ian Goldberg wrote: > > To be explicit, removing support for OTRv1 from libotr 3.x is totally > fine (and indeed libotr 4.x has already done it). Ian, thanks a lot for the input. I guess it's all good then, no objection for an NMU and thanks in advance to whoever will deal with it. I hope to be able to resume my normal DD duties ASAP ;P T-Bone ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bug#725779: libotr: OTR clients supporting both OTRv1 and v2 are subject to protocol downgrade attacks
On Wed, Oct 23, 2013 at 12:35:09AM +0200, Thibaut Varène wrote: > > intrig...@debian.org wrote (08 Oct 2013 09:27:56 GMT) : > >> as you are surely aware of, it's been known [1] since 2006 that > >> clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject > >> to protocol downgrade attacks clients. It's also been known for > >> a while that OTRv1 has serious security issues (that were the main > >> reason for a v2, actually). In short, support v2 only is the only safe > >> way to go these days. > > > >> [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.165.7945 > > > >> It took a while to obsolete older v1-only software, and another while > >> to complete the libotr 4.x transition and get to a sane state in > >> Debian testing. Now, I think the time has come when we can reasonably > >> expect v2-only to work for everyone. > > > >> I think that the only reasonable course of action from now on is to > >> patch libotr in stable and oldstable to only support OTR v1. > > > > (s/v1/v2/ in the last sentence, obviously.) > > > > Ping? If you have no time to take care of that, fair enough, but then > > I would really appreciate to read your general opinion on the matter, > > even if it's a simple "please go ahead and NMU". Thanks in advance! > > I have to admit having absolutely no time to deal with that. If everyone is > fine this won't be disruptive for existing users of otr (it's not entirely > clear to me what the implications of such a change are, TBH), you're more > than welcome to NMU if you're confident this is The Right Thing(tm). > > Cheers, > > T-Bone To be explicit, removing support for OTRv1 from libotr 3.x is totally fine (and indeed libotr 4.x has already done it). - Ian ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bug#725779: libotr: OTR clients supporting both OTRv1 and v2 are subject to protocol downgrade attacks
On 22 oct. 2013, at 20:17, intrigeri wrote: > Hi Thibault, Hi, > > intrig...@debian.org wrote (08 Oct 2013 09:27:56 GMT) : >> as you are surely aware of, it's been known [1] since 2006 that >> clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject >> to protocol downgrade attacks clients. It's also been known for >> a while that OTRv1 has serious security issues (that were the main >> reason for a v2, actually). In short, support v2 only is the only safe >> way to go these days. > >> [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.165.7945 > >> It took a while to obsolete older v1-only software, and another while >> to complete the libotr 4.x transition and get to a sane state in >> Debian testing. Now, I think the time has come when we can reasonably >> expect v2-only to work for everyone. > >> I think that the only reasonable course of action from now on is to >> patch libotr in stable and oldstable to only support OTR v1. > > (s/v1/v2/ in the last sentence, obviously.) > > Ping? If you have no time to take care of that, fair enough, but then > I would really appreciate to read your general opinion on the matter, > even if it's a simple "please go ahead and NMU". Thanks in advance! I have to admit having absolutely no time to deal with that. If everyone is fine this won't be disruptive for existing users of otr (it's not entirely clear to me what the implications of such a change are, TBH), you're more than welcome to NMU if you're confident this is The Right Thing(tm). Cheers, T-Bone ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Bug#725779: libotr: OTR clients supporting both OTRv1 and v2 are subject to protocol downgrade attacks
Hi Thibault, intrig...@debian.org wrote (08 Oct 2013 09:27:56 GMT) : > as you are surely aware of, it's been known [1] since 2006 that > clients supporting both OTRv1 and v2 (such as libotr 3.x) are subject > to protocol downgrade attacks clients. It's also been known for > a while that OTRv1 has serious security issues (that were the main > reason for a v2, actually). In short, support v2 only is the only safe > way to go these days. > [1] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.165.7945 > It took a while to obsolete older v1-only software, and another while > to complete the libotr 4.x transition and get to a sane state in > Debian testing. Now, I think the time has come when we can reasonably > expect v2-only to work for everyone. > I think that the only reasonable course of action from now on is to > patch libotr in stable and oldstable to only support OTR v1. (s/v1/v2/ in the last sentence, obviously.) Ping? If you have no time to take care of that, fair enough, but then I would really appreciate to read your general opinion on the matter, even if it's a simple "please go ahead and NMU". Thanks in advance! 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] Tor Launcher extension [Was: Mike's March 2013]
Hi Mike, hi Pearl Crescent team! Mike Perry wrote (02 Apr 2013 08:52:56 GMT) : > Thus spake intrigeri (intrig...@boum.org): >> 1. Any obvious showstopper, off the top of your head, regarding how >>the Tor Launcher could be usable for Tails? > I think you guys mostly won't use it. Back in April, I was inclined to agree, and we had someone who volunteered to take over the maintenance of Vidalia. Since then, that "someone" disappeared. Vidalia's lack of a maintainer is a more and more serious issue for us (e.g. the great bridges support plan was implemented in the 0.4.x alpha branch, and never landed into a stable release yet). Vidalia being what it is, I doubt we want to maintain it ourselves. So, I'm willing to give the "use Tor Launcher in Tails" idea another chance. Also, it would be really awesome if all major ways of using Tor (TBB, Tails, etc.) could provide the same interface for configuring how Tor should access the network. This would make documentation work (and thus, translation work) easier, and make user experience way better IMHO. The thing is, it seems to me that Tails cannot really use Tor Launcher in its current state, for a few reasons: * we want to stop starting a web browser by default; * we would rather *not* give the desktop user, that runs the web browser, full rights on configuring Tor; we just stopped doing this, actually. With all this in mind, I was almost tempted to just replicate the Tor Launcher UI in our custom GDM greeter, but it would be quite sad, and not necessarily easy to integrate nicely in there. And then, someone suggested turning Tor Launcher into an autonomous XUL application. I've not thought this through yet, but it does seem this would be enough to allow us to simply s/Vidalia/Tor Launcher/. Are there plans to do so? How hard would you expect it to be for someone skilled in this area? Would you want to do it, for the sake of the greater Tor community? 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 feature/consistent-persistence-path
Hi, Merged, building on lizard. Actually, the branch as proposed for merging was basically a no-op, as merging testing in it brought in a revert of the interesting code (as that branch had been merged by mistake, then reverted, in the 0.20 cycle IIRC). So I had to revert the revert, woo! This also required me to prepare a new release of tails-greeter (now in testing & devel). So the end-result might be slightly different from the state that was tested => sajolida, I would be very happy if you could test the resulting ISO (e.g. from a nightly build) behaves as intended. 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 bugfix/world-readable-persistence-state-file
On Fri, Oct 18, 2013 at 02:19:13PM +0200, intrigeri wrote: > Hi, > > * branch: bugfix/world-readable-persistence-state-file, both in the > tails-greeter and main Git repositories (+ APT) > * ticket: https://labs.riseup.net/code/issues/6374 > > This branch fixes #6374, that was discovered while testing 0.21~rc1 > today. Please review'n'merge in time for the final 0.21. > > Tested by live patching a 0.21~rc1, and also in a build > from experimental. Tested in a VM upgrading a 0.20.1 usb with an iso of this branch, I get the error message that t-p-s can't delete the persistent partition when it is activated. Merged and pushed. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Control Port / Timing of the move to FF24
adrelanos wrote (22 Oct 2013 04:24:06 GMT) : > I think it won't leave anyone's wishes for features open, even has a .d > config folder - unless you'd like to see a rewrite in something other > than bash. > So if you like my implementation or have any feature requests, I may be > able to polish it and to host it in its own git repository. Would be > glad if you like it. But please don't ask me for tested Tails patches, I > am not good at that. Thank you, noted down your help offer to the ticket. 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] Old unresolved security-related Firefox issue
The security of Firefox/Iceweasel is important for the security of Tails. I therefore suggest to have a look at this old unresolved Firefox issue and vote for it. Years ago people working for RedHat spent a lot of time to create a patch which does not yet seem to have been applied. Resolving the issue would make Firefox more secure (even when SELinux is not used): SELinux is preventing JIT from changing memory segment access https://bugzilla.mozilla.org/show_bug.cgi?id=506693 Cheers, Andreas ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
