Hi, Kill Your TV wrote (14 Nov 2013 20:32:45 GMT) : > If ACLs can be used [...]
I've no idea if they're available for SquashFS, especially once combined with aufs. One would have to test this. Let's perhaps keep this for a future iteration, though, and make sure it does not block the basics from landing into 0.22. > At the very worst we could fix it with documentation. "Set a root > password if you want access to _______". Sure, this would be a great improvement over the current situation. >> >> 5. I read this: >> >> > * Boostrap through 127.0.0.1:8118 >> >> >> >> This is an important change to how Tails has been using I2P >> >> until now. If our brand new I2P maintainer says it's better to >> >> have it go through Tor, I'm very happy. Is it now *entirely* going >> >> through Tor, that is, can we drop the firewall exception that >> >> allows I2P to go out in the clear, and update the design doc >> >> accordingly? Or is it only the bootstrap step that goes over Tor? >> >> > Only the initial reseeding/bootstrapping would happen over Tor. >> >> OK, then: >> >> * Why the change to make it bootstrap over Tor? > Since the bootstrap happens over HTTPS and/or HTTP and Tails exposed > port 8118 it seemed like a good candidate. Sorry if I'm thick, but I still don't get what is the advantage of doing this, while I clearly see a few disadvantages (slowness, potential for fingerprinting of Tails users, and makes it harder to drop the HTTP proxy). >> * Why not have the whole I2P thing to go over Tor? > Slowness. It would be rather "painful". Fair enough. > RE: the gettextish strings in > config/chroot_local-includes/usr/share/i2p/docs/initialNews, it seems > the strings for the news files in I2P are extracted from the Java > source and what I modified (and added) was a template of sorts. Either > I can remove the gettext bits or remove the custom file. I removed the > gettext strings locally but I've not checked it in because maybe going > with the I2P default would be preferred. This initial news file will > only be displayed until an updated one is downloaded via I2P. In my > testing this tends to happen within a few minutes. The only thing I care in that area is that we should not introduce i18n regressions: if we replace a i18n'd upstream file, our version must be i18n'd too. If that's too much work compared to the limited benefit, let's just keep upstream's file. Your call :) > (Future merges will go *much* more smoothly..) Sure :) Cheers! -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc _______________________________________________ tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev
