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
