Re: [Tails-dev] Tor Browser branding in Tails?
arkmd wrote (02 Dec 2013 01:36:23 GMT) : intrigeri: how annoying do you think it is if some of the Tor Browser branding (mainly: window title bar, some text in About Tor Browser) is applied in Tails 0.22? I guess we could change this by dropping the Tor Browser's official .mozconfigs patch. To be honest, I'm a bit reluctant to change this *now* for 0.22 (frozen, will be released in a bit more than a week), and I'm afraid we did not think of this earlier in this release cycle, but I would be happy to fix this for 0.23 if you think it's required. Is it to avoid confusion? No, it's to have our browser codebase as close as possible to the regular Torbrowser's one. Each patch we drop has the potential to make our browser look somewhat different on the Internet. Thats a valid point, but... A big Tor Browser title bar would attract more attention of the people standing around than it would help new Tails users. Maybe stay with Iceweasel, or even change name and icons to Firefox, would provide more discretion to Tails users. Personally, I believe the Windows Camouflage mode is our best bet when it comes to hiding one is using something weird. I guess we would take patches that s/Tor Browser/Firefox/ or something in camouflage mode, but I don't consider this as a valid line of reasoning as far as non-camouflage mode is concerned. If others think differently, I'm happy to read their thoughts and perhaps change my mind :) 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 Browser branding in Tails?
02/12/13 09:53, intrigeri wrote: arkmd wrote (02 Dec 2013 01:36:23 GMT) : intrigeri: how annoying do you think it is if some of the Tor Browser branding (mainly: window title bar, some text in About Tor Browser) is applied in Tails 0.22? I guess we could change this by dropping the Tor Browser's official .mozconfigs patch. To be honest, I'm a bit reluctant to change this *now* for 0.22 (frozen, will be released in a bit more than a week), and I'm afraid we did not think of this earlier in this release cycle, but I would be happy to fix this for 0.23 if you think it's required. Is it to avoid confusion? No, it's to have our browser codebase as close as possible to the regular Torbrowser's one. Each patch we drop has the potential to make our browser look somewhat different on the Internet. Thats a valid point, but... A big Tor Browser title bar would attract more attention of the people standing around than it would help new Tails users. Maybe stay with Iceweasel, or even change name and icons to Firefox, would provide more discretion to Tails users. Personally, I believe the Windows Camouflage mode is our best bet when it comes to hiding one is using something weird. I guess we would take patches that s/Tor Browser/Firefox/ or something in camouflage mode, but I don't consider this as a valid line of reasoning as far as non-camouflage mode is concerned. Given how widely used Firefox is among Windows systems this looks like a good idea, especially since Iceweasel should be able to make a less suspicious impersonation of Firefox than it currently does of Internet Explorer. This thought did occur to me when developing this feature, but it has a catch... If others think differently, I'm happy to read their thoughts and perhaps change my mind :) My only objection is that this would make Tails potentially illegal for us to distribute. Mozilla's artwork is non-free, as is the use of the Firefox name in some sense [1], which are among the reasons for Iceweasel existing in the first place. [1] http://www.mozilla.org/en-US/foundation/trademarks/policy/ Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] What to do with Firefox 17.0.11ESR?
Alan wrote (30 Nov 2013 11:38:39 GMT) : On Fri, 29 Nov 2013 12:25:33 +0100 intrigeri intrig...@boum.org wrote: Now that the RC is 3 days away from now, and my email [1] to pkg-mozilla about fixing NSS in squeeze-backports is still unanswered, I believe the best course of action is indeed to advertise the RC more strongly than usual (by having the security issue notification explicitly suggest to use the RC). Seems the best we can realistically do. Please see my attempt to do that in wiki/src/security/Numerous_security_holes_in_0.21.mdwn (testing branch). Is it strong but careful enough? 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 Browser branding in Tails?
02/12/13 09:50, intrigeri wrote: anonym wrote (01 Dec 2013 23:51:06 GMT) : I guess we could change this by dropping the Tor Browser's official .mozconfigs patch. To be honest, I'm a bit reluctant to change this *now* for 0.22 (frozen, will be released in a bit more than a week), and I'm afraid we did not think of this earlier in this release cycle, but I would be happy to fix this for 0.23 if you think it's required. It should be noted that our user documentation mentions Iceweasel several times so that discrepancy may be a source of use confusion, which may warrant a (potentially temporary) change in the user documentation. Switching the name to Tor browser in 0.22, and then back to Iceweasel in 0.23 will perhaps also generate some confusion. I feel inclined to say that *if* we release 0.22 with the current Tor browser branding, then we stick with it. Perhaps that'll even be good for consistency with Tor's product, whom many Tails users presumably have used before trying out Tails? OTOH, maybe the Tor people will object since there are differences (-/+ some patches, adblock, etc.)? From a general Tails dev perspective I agree with this reasoning. With my RM hat I'm hoping whatever decision we make results in us not touching these bits for 0.22. Fully understood. If the title change is kept in 0.22, we must at least make that very clear in the release announcement, especially if the docs aren't updated. Furthermore, if we treat this a mistake that we're gonna revert, I think we should fix it in the first 0.22 point-release if there will be one. I don't see the point in waiting until 0.23. Or did I miss anything? Cheers! ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
[Tails-dev] Please review'n'merge bugfix/back-to-linux-3.10 [Was: Fix sdmem on Intel graphic hardware, please review]
Hi, intrigeri wrote (01 Dec 2013 19:19:51 GMT) : winterfa...@riseup.net wrote (01 Dec 2013 17:32:44 GMT) : Please test that it fixes it for you too, and please verify that the memory still is wiped. Woo! Currently building an ISO to test this. The resulting ISO does not fix the problem for me. I've merged testing into the branch, merged it into experimental, and pushed to both origin lizard, so the next nightly build from experimental will have this change. winterfairy, can you please try such an ISO and reproduce that it really fixes the bug for you? I just run a bunch of tests on three different laptops. Below, emergency means that I've removed the boot USB stick once the greeter appeared, applet means that I've used the GNOME panel applet to shutdown the system, and N/M means N successes on M attempts. ThinkPenguin Royal: * 0.22~rc1: emergency = 0/3, applet = 0/3 * bugfix/sdmem_on_intel_gpu: emergency = 0/3, applet = 0/3 * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 ThinkPad X201: * bugfix/sdmem_on_intel_gpu: emergency = 1/3, applet = 1/3 * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 ThinkPad X32: * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 So, I'm hereby requesting a review'n'merge of bugfix/back-to-linux-3.10 into testing and devel (there's an APT merge to do, too). bertagaz will take care of it. Merged into experimental, pushed to origin and lizard so the next nightly build from experimental will have this stuff. Once this branch is merged, I'll file a ticket to unblock the situation later, as we can't ship Linux 3.10 forever, and will edit the call for testing 0.22~rc1 so that we get feedback from non-Intel-graphics users and hopefully understand better who's affected exactly. Adding DRM modules to the initramfs might be part of the solution, but I'd rather not do this at post-RC time, since our last similar attempt (in Tails 0.12, see commit 901461) was a complete failure. We'll want DRM modules for #5948 (custom plymouth theme), by the way. 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/back-to-linux-3.10 [Was: Fix sdmem on Intel graphic hardware, please review]
intrigeri wrote: I just run a bunch of tests on three different laptops. Below, emergency means that I've removed the boot USB stick once the greeter appeared, applet means that I've used the GNOME panel applet to shutdown the system, and N/M means N successes on M attempts. ThinkPenguin Royal: * 0.22~rc1: emergency = 0/3, applet = 0/3 * bugfix/sdmem_on_intel_gpu: emergency = 0/3, applet = 0/3 * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 ThinkPad X201: * bugfix/sdmem_on_intel_gpu: emergency = 1/3, applet = 1/3 * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 ThinkPad X32: * bugfix/back-to-linux-3.10: emergency = 3/3, applet = 3/3 So, I'm hereby requesting a review'n'merge of bugfix/back-to-linux-3.10 into testing and devel (there's an APT merge to do, too). bertagaz will take care of it. Merged into experimental, pushed to origin and lizard so the next nightly build from experimental will have this stuff. Once this branch is merged, I'll file a ticket to unblock the situation later, as we can't ship Linux 3.10 forever, and will edit the call for testing 0.22~rc1 so that we get feedback from non-Intel-graphics users and hopefully understand better who's affected exactly. My tests, applet only (success/total): * before any fix: 0/3 * sdmem_on_intel_gpu [1]: 2/3 * back-to-linux-3.10 [2]: 3/3 Apparently my fix does not fix it completely, so reverting to an older kernel version seems to be the most sane thing to do right now, yes. I won't try to fix this problem anymore, so unless anyone else is up to it, we have to hope a future linux kernel version works again. I believe the underlying problem is that kexec doesn't play well with all drivers/hardware, since they are not properly deinitialized or cannot be properly deinitialized, leaving memory-mapped regions the newly loaded kernel does not know about. The longstanding known issues page lists similar problems for other computers, some with non-Intel graphic hardware. [1] tails-i386-experimental-0.23-20131202T0830Z-07817d7.iso [2] tails-i386-experimental-0.23-20131202T1339Z-92b9fbb.iso ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Scripts for importing Transifex translations, please review
intrigeri wrote: winterfairy wrote: For the other repositories: The bug says something about Makefile targets, but it is okay that it is a script, right? And that the user must manually invoke the script to pull translations, just like in the tails repo right now? I think it's a very good first step. Do you think it is enough to resolve the ticket (#6207)? For the Perl software, I'll probably integrate running this script into the automated Dist::Zilla release workflow, but I guess it's fine to require the person doing the release to run an additional command here and there. It is easier for me to just add the script (and adjust it for this repository and po-style). If that is enough to resolve the ticket, I will not spend much work on trying to integrate it with any automated release workflows, unless it is somewhat obvious to me how to integrate it. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Tor Browser branding in Tails?
On Mon, Dec 02, 2013 at 09:50:15AM +0100, intrigeri wrote: Hi, anonym wrote (01 Dec 2013 23:51:06 GMT) : I'm worried that this may fail several scenarios (and even complete features) in the automated test suite. Does the new branding also change the icon in the window title? Please see features/images/IceweaselRunning.png -- does that part of the new Iceweasel/Tor browser still look the same? (Sorry, I don't have time (or the bandwidth) to check this myself right now.) The window titlebar icon doesn't change so I hope it does not break the test suite. bertagaz will be running it today, so we'll soon know. It doesn't. The unsafe browser feature/image does though. bert. ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Removing packages from Tails for testing smaller attack surface
Thanks! On Sat, Nov 30, 2013 at 10:11 AM, intrigeri intrig...@boum.org wrote: Hi, Thomas Benjamin wrote (29 Nov 2013 23:14:42 GMT) : Is there any particular good procedure for removing packages from Tails, Not really, sorry. (and I don't understand why the -f parameter is not used so that the build will not fail if that package is not included). It is intentional that the build fails if we're trying to delete something we didn't install in the first place, so that we notice when we have obsolete cruft that we should get rid of. Sorry, this is optimized for maintainability more than for making customization easy. 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 -- Sincerely Yours, Thomas S. Benjamin ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
