Re: [Tails-dev] [review'n'merge 1.2] feature/7725-i2p-browser
Hi,
27/09/14 12:53, Kill Your TV wrote:
> On Fri, 26 Sep 2014 16:25:14 + (UTC)
> anonym wrote:
>
>
>> First of all, great work! It works really good, and works pretty
>> nicely as-is. I have some doubts about it making it into Tails 1.2,
>> which I attribute to me being so late with reviewing. I could
>> consider merging it with if you commit strongly to be available to
>> fix things post-freeze. What do you think? IMHO you should prioritize
>> getting feature/7732-i2p-network-manager-hook ready for merge, though.
>
> Assuming I'm not hit by a bus in the meantime, I'll be around for
> fixing up things post-freeze.
Great!
>> Now for some commit-specific remarks:
>>
>>> commit 79f87a1b Hide bookmark/history
>>
>> Interesting. See https://labs.riseup.net/code/issues/7948 . Maybe what
>> you suggest is actually better, since the start page is the router
>> console and as a portal it definitely beats a lousy bookmarks folder.
>> Actually the (unstated) rationale for #7948 was mostly to have the
>> router console easily available.
>
> I did what made the most sense to me at the time but I am open to
> changes, ofc. :)
Your way is much nicer so let's leave it.
Oh, and regarding commit d45c28e, the I2P bookmarks should be completely
removed from the Tor Browser (completely removed, in other words).
>>> commit 2b0fe4a hide "get addons" in addon-manager
>>
>> Also interesting. This should be back-ported into the Unsafe Browser
>> too, imho. Well, the correct thing to do would be to make a shell
>> library to make task-specific chroot browsers, but that's a post-1.2
>> goal.
>>
>> Can it be taken to the next level, i.e. disabling altering the add-ons
>> completely?
>
> It's likely doable but I don't know how at the moment. If it's doable I
> can almost certainly figure it out for 1.2.1 or 1.3.
Filed as: https://labs.riseup.net/code/issues/7970 and optimistically
assigned to you.
>>> commit d264cc9 Switch I2P-Browser from Iceweasel to Tor-Browser
>>
>> Why not installing Torbutton too, and configuring it to use I2P
>> instead? I imagine the protections it adds also make sense for I2P?
>> If so, this is a regression (in terms of "security") from the
>> FoxyProxy-way of doing this.
Torbutton is shown with a red X on it, which looks scary. I wonder if
the misconfiguration causing it puts Torbutton in a state in which some
important defence/feature is disabled, or if it's just an indication of
misconfiguration. Any way, we don't want to show the button at all
because the "New feature" thing won't work and hence will be misleading.
If you set `extensions.torbutton.inserted_button = true` it will be hidden.
So, I suggest the following patch, which I verified works; it both makes
configures Torbutton so that it doesn't show the X, *and* it removes the
button... pedantic, perhaps, but at least we don't have to worry about
the the question about Torbutton disabling features in the "red X"
stateu. :)
---
/lib/live/mount/rootfs/filesystem.squashfs/usr/local/sbin/i2p-browser
2014-09-29 00:51:51.0 +
+++ /usr/local/sbin/i2p-browser 2014-09-29 02:09:13.678449711 +
@@ -182,13 +182,14 @@
${BROWSER_PREFS}
# add the I2P proxy to all protocols
cat > "${BROWSER_PREF_DIR}/i2p.js" << EOF
-user_pref("network.proxy.http", "127.0.0.1");
-user_pref("network.proxy.http_port", );
-user_pref("network.proxy.ftp", "127.0.0.1");
-user_pref("network.proxy.ftp_port", );
-user_pref("network.proxy.ssl", "127.0.0.1");
-user_pref("network.proxy.ssl_port", );
-user_pref("network.proxy.share_proxy_settings", true);
+user_pref("extensions.torbutton.inserted_button", true);
+user_pref("extensions.torbutton.settings_method", "custom");
+user_pref("extensions.torbutton.custom.http_proxy", "127.0.0.1");
+user_pref("extensions.torbutton.custom.http_port", );
+user_pref("extensions.torbutton.custom.https_proxy", "127.0.0.1");
+user_pref("extensions.torbutton.custom.https_port", );
+user_pref("extensions.torbutton.custom.ftp_proxy", "127.0.0.1");
+user_pref("extensions.torbutton.custom.ftp_port", );
user_pref("network.proxy.no_proxies_on", "127.0.0.1");
EOF
# Hide options in the I2P Browser.
> I think the changes requested have been addressed. Please see the
> latest pushed commits.
After these things are fixed, and the user documentation has been
upgraded at `wiki/src/doc/anonymous_internet/i2p.mdwn`, I believe it's
ready to be merged.
Again, great work!
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
28/09/14 02:42, intrigeri wrote: > Hi, > > anonym wrote (12 Sep 2014 15:18:55 GMT) : >> 2014-09-28 Feature freeze >> 2014-09-29 Tag 1.2-rc1 in Git >>Build and upload 1.2-rc1 ISO/IUKs >> 2014-09-30 Test 1.2-rc1 >> 2014-10-01 Release 1.2-rc1 > > I've got a few concerns with this schedule: > > 1. we won't have Firefox ESR31 (Mike Perry told me the TBB team should >have something ready based on ESR31 by the end of next week -- >let's assume Oct. 4); given that's the one major change in this >release, it feels a bit weird not to have it in the RC; Ouch... I somehow thought that the 4.x bundles already had migrated to ESR31. > 2. the other major change (migration to Tor Browser) isn't ready for >prime-time yet, and our track records wrt. fixing stuff in a rush >in between the RC and the final release isn't that good, be it in >terms of quality (in a rush, we sometimes had to merge stuff that >was not as good than what we would usually want to merge) or of >stress level for everyone involved (testers, developers, >reviewers); Agreed. Right now there's only one ticket left, though. That said, there may be some undiscovered issues... > 3. I won't have time to bring my AppArmor work to completion in time, >and the next major release is scheduled for mid-February. Let's say >this is not a decisive factor in itself, but let's just keep it in >mind, OK? :) IMHO, this may be a blocker. See below. > So, I wonder if, maybe, it would be a good idea to postpone the RC > a bit, say: > >2014-10-05 Import the new Tor Browser 4.0-something based on > Firefox ESR31; adjust what needs to be adjusted (I can > commit to be available and help with testing, > identifying issues, review'n'merging) Would you be available for this on 2014-10-07 (see below)? >2014-10-06 Finish the above, build and upload RC ISO/IUKs I may be wrong, but given that we won't have to build our own Iceweasel, I think only one day will be needed for all of the image preparation. That is unless the ESR31 bump introduces issues for us, which it very well may. >2014-10-07 Test and release 1.2~rc1 (I can commit to help with > the test suite and some bits of the release process, > e.g. translating the changelog into the end-user > announce) I unfortunately have other plans during this time. I will be completely unavailable starting the afternoon (CEST) on Friday, 2014-10-03, and I should be back again some time on Monday, 2014-10-06, but I can only guarantee availability starting the morning (CEST) of Tuesday, 2014-10-07. > The main problem with this is that it only leaves 4 days between the > RC is out, and the time anonym builds the final ISO. The main > advantages are that these 4 days can be used to test the actual code > we want to see in 1.2, and that it leaves anonym and I (and maybe Kill > Your TV too) seven more days to complete our work. But it will be problematic for the translators... > Also, IIRC last time there was an ESR major version bump, the TBB team > has been fixing things until the last minute, so I'm not that > confident that the final ISO can actually be built on 2014-10-12 as > planned. If that's postponed by 1-3 days, then the RC testing period > gets a bit longer. Right. First of all, I'd hate it if your AppArmor work and kytv's remaining I2P improvements wouldn't make it into 1.2, especially since that would delay them for over four months (!) if we follow our policy strictly. Combine that with my unavailability and that my work on the TBB migration probably will need some more polishing, and I feel open to delaying our release a bit. I suggest the following new release schedule: 2014-10-07 Tag 1.2-rc1 in Git Build and upload 1.2-rc1 ISO/IUKs 2014-10-08 Test and release 1.2-rc1 2014-10-15 TBB 4.0 is hopefully officially released Tag 1.2 in Git Build and upload 1.2 ISO and IUKs 2014-10-16 Test and release Tails 1.2 While this only delays our release two days, it gives us a week of RC testing, bug fixing and translation work, and it reduces the risk of painful timing issues with the TBB 4.0 release. Testing and releasing on the same day should work (it was done for 1.1.2) if there's one (but two would be great!) dedicated testers (excluding me) available from around 10:00 CEST on these two days. What do you think? Who would be available for testing? 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
Hi, > So, I wonder if, maybe, it would be a good idea to postpone the RC > a bit, say: > >2014-10-05 Import the new Tor Browser 4.0-something based on > Firefox ESR31; adjust what needs to be adjusted (I can > commit to be available and help with testing, > identifying issues, review'n'merging) >2014-10-06 Finish the above, build and upload RC ISO/IUKs >2014-10-07 Test and release 1.2~rc1 (I can commit to help with > the test suite and some bits of the release process, > e.g. translating the changelog into the end-user > announce) > [...] > Thoughts? > Looks good. Having the wrong firefox/tor browser in the RC seems not so good. ___ 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.
