[Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi,
Kill Your TV wrote (08 Nov 2013 14:52:33 GMT) :
> On Mon, 4 Nov 2013 11:41:50 + (UTC)
> intrigeri wrote:
> [...]
>> I think the best way to handle it is:
>>
>> * killyourtv maintains a Tails-experimental suite in their APT
>> repository.
> Done. The sources line is:
>deb http://deb.i2p2.no tails-experimental main
> As promised previously, the packages in this repo will not change until
> after the next Tails release.
Once we have pulled the relevant packages from there into our own
repo, you are welcome to unfreeze this APT suite :)
>> * Optional: we patch auto/scripts/tails-custom-apt-sources to
>> include this suite when building from our experimental branch.
>> This makes the next step easier.
> I haven't done this (but could take a stab at it).
Cool. The relevant Cucumber feature (features/build.feature) should help.
>> * When s/he wants Tails to get a newer version of I2P, killyourtv
>> uploads it to their Tails-experimental APT suite and asks for
>> a review'n'merge. Most of the times, no change is needed in Tails
>> source code, but when it's needed, then the review'n'merge request
>> must include a feature/i2p-$version branch.
> I think I'm ready to have other eyes on it. I branched off of 'devel' a
> few days ago.
>
> http://repo.or.cz/w/tails/kytv.git/shortlog/refs/heads/feature/i2p-0.9.8.1
> My commit comments tend to be verbose but hopefully they're not _too_
> wordy for your use.
IMHO it's hard to have too verbose commit messages.
Also, next time, please set the email subject so that it's clear it is
a review'n'merge request (e.g. in case someone has no time to read the
entire thread, but still wants to keep an eye on what is proposed for
merging once conclusions have been reached).
Here is a first review review pass.
First, congrats, impressive work!
1. Regarding adding I2P IRC channels: great; please not that, without
a proper upstream solution in Pidgin that allows the user to
understand what the non-obvious @127.0.0.1 and @XXX.onion accounts
are (Tails#6232), I'm not sure we will keep these enabled for long.
2. Why the (undocumented) switch from `set -e' to `/bin/sh -e'?
I generally prefer the former, as it's in effect even when someone
mistakenly runs the script e.g. with "sh $SCRIPT".
3. I read this:
> * Disable "in-network" updates (this is also done in the regular I2P
packages)
What are "in-network" updates?
What are the "regular I2P packages"?
4. I read this:
> * relaxed permissions so that both the i2psvc user and the i2psvc group
have access
Access to what, and why is it useful / needed for?
I assume this documents this change:
> # Loosen wrapper permissions so that the amnesia user (who'll be added to
the i2psvc group) has access
> sed -i 's|^.*\(wrapper.*umask=\).*|\10007|g' "$WRAPPER"
and:
> # * insecure files: Enabled. This means that permissions will not be forced
> # to 700 for the i2psvc user, giving i2psvc group members access.
... that don't tell me much either.
A further commit reads "Add the amnesia user to the i2psvc group",
"This will allow the standard Tails user to access the I2P config
directory." Same question: what is it useful for? Does this *only*
adds access to that directory, or does it gives the desktop user
other credentials as a side effect? If access to that directory is
really needed, and only that, perhaps we could use an ACL instead?
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?
Also, is it possible to use the Tor SOCKS proxy, rather than going
through polipo? (We're at the point we can almost ditch it
entirely, and stop shipping a HTTP proxy in Tails, so adding
a usecase for it makes me sad.)
6. This is pretty bold affirmation:
> # Settings that are set or unset in this file will be useful for all
versions
> # of Tails.
... but well :)
7. I see /usr/share/i2p/docs/initialNews/initialNews.xml uses some
gettext'ish _("") syntax, but I don't see how and when the strings
are extracted. See the refresh-translations script.
8. I read "Add exceptions to ferm for the standard I2P ports".
Please document what these ports are useful for.
9. In the revised design doc, I read:
> The I2P hosts an [APT repository](http://deb.i2p2.no)
Missing word, or is it me lacking knowledge about I2P?
10. I also read:
> 2. The local *eepsite*: urls matching one of the
> `http://127.0.0.1:7658/*` and `http://localhost:7658/*` wildcard
> patterns will get a direct conne
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Sat, 9 Nov 2013 13:28:49 + (UTC) intrigeri wrote: > > As promised previously, the packages in this repo will not change > > until after the next Tails release. > > Once we have pulled the relevant packages from there into our own > repo, you are welcome to unfreeze this APT suite :) I figured. > >> * Optional: we patch auto/scripts/tails-custom-apt-sources to > >> include this suite when building from our experimental branch. > >> This makes the next step easier. > > > I haven't done this (but could take a stab at it). > > Cool. The relevant Cucumber feature (features/build.feature) should > help. Excellent. > > > My commit comments tend to be verbose but hopefully they're not > > _too_ wordy for your use. > > IMHO it's hard to have too verbose commit messages. I agree but some have complained in the past so until I hear otherwise I default to verbose. > Also, next time, please set the email subject so that it's clear it is > a review'n'merge request (e.g. in case someone has no time to read the > entire thread, but still wants to keep an eye on what is proposed for > merging once conclusions have been reached). Understood. > Here is a first review review pass. > > First, congrats, impressive work! TY :) (There are more things that need addressing than I would like; some of which I noticed _after_ I sent the email (as luck would have it)). > 1. Regarding adding I2P IRC channels: great; please not that, without >a proper upstream solution in Pidgin that allows the user to >understand what the non-obvious @127.0.0.1 and @XXX.onion accounts >are (Tails#6232), I'm not sure we will keep these enabled for long. It's not a problem if it goes away. > 2. Why the (undocumented) switch from `set -e' to `/bin/sh -e'? >I generally prefer the former, as it's in effect even when someone >mistakenly runs the script e.g. with "sh $SCRIPT". Good point. I'll explicitly set it on its own line. (Why was it done? A bad habit that I need to break from.) > 3. I read this: >> * Disable "in-network" updates (this is also done in the regular >> I2P packages) >What are "in-network" updates? >What are the "regular I2P packages"? In-network updates are how non-packaged versions of I2P receive updates. Since the packaged versions have a read-only installation directory the "in-network" updates would be disabled anyway. By "regular packages" I meant, in essence, "any time that I2P is installed from a .deb. That is so say, this is not a change from upstream." > 4. I read this: >> * relaxed permissions so that both the i2psvc user and the >> i2psvc group have access >Access to what, and why is it useful / needed for? >I assume this documents this change: >> # Loosen wrapper permissions so that the amnesia user (who'll be >> added to the i2psvc group) has access sed -i >> 's|^.*\(wrapper.*umask=\).*|\10007|g' "$WRAPPER" >and: >> # * insecure files: Enabled. This means that permissions will >> not be forced # to 700 for the i2psvc user, giving i2psvc >> group members access. >... that don't tell me much either. It was intended to give access to /var/lib/i2p to the standard amnesia user so that s/he could make changes without needing 'sudo' By default the Java Service Wrapper is configured thusly: # Set permissions used when creating files # See http://wrapper.tanukisoftware.com/doc/english/prop-umask.html # for a detailed explanation of these settings. wrapper.umask=0022 wrapper.java.umask=0022 wrapper.logfile.umask=0077 This effectively means that the i2psvc user is the only one with read/write access. Others, including the i2psvc group, cannot write to /var/lib/i2p. Potential problems with this default set-up for a Tails user who does not set a password prior to logging in: - If a Tails user tried to start I2P and it failed for some reason, s/he may be advised to look in /var/log/i2p. Due to the default umask set, the amnesia user cannot access it. - If a Tails user (for whatever reason) decided to download an I2P-internal torrent, any such files would be lost. - If a Tails user wanted to set up an 'eepsite' (be it temporarily to share something quickly or something a bit more long term once we have persistence enabled), s/he wouldn't be able to access that folder >A further commit reads "Add the amnesia user to the i2psvc group", >"This will allow the standard Tails user to access the I2P config >directory." Same question: what is it useful for? Does this *only* >adds access to that directory, or does it gives the desktop user >other credentials as a side effect? If access to that directory is >really needed, and only that, perhaps we could use an ACL instead? The only extra access /should/ be only to access that directory without requiring admin access being set upon logging in. If we have ACLs available to us with Tails, this indeed would be another way to solve this
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi, Kill Your TV wrote (09 Nov 2013 16:33:56 GMT) : > On Sat, 9 Nov 2013 13:28:49 + (UTC) > intrigeri wrote: >> 4. I read this: >>> * relaxed permissions so that both the i2psvc user and the >>> i2psvc group have access >>Access to what, and why is it useful / needed for? >>I assume this documents this change: >>> # Loosen wrapper permissions so that the amnesia user (who'll be >>> added to the i2psvc group) has access sed -i >>> 's|^.*\(wrapper.*umask=\).*|\10007|g' "$WRAPPER" >>and: >>> # * insecure files: Enabled. This means that permissions will >>> not be forced # to 700 for the i2psvc user, giving i2psvc >>> group members access. >>... that don't tell me much either. > It was intended to give access to /var/lib/i2p to the standard amnesia > user so that s/he could make changes without needing 'sudo' By default > the Java Service Wrapper is configured thusly: > # Set permissions used when creating files > # See http://wrapper.tanukisoftware.com/doc/english/prop-umask.html > # for a detailed explanation of these settings. > wrapper.umask=0022 > wrapper.java.umask=0022 > wrapper.logfile.umask=0077 > This effectively means that the i2psvc user is the only one with > read/write access. Others, including the i2psvc group, cannot write > to /var/lib/i2p. Potential problems with this default set-up for a > Tails user who does not set a password prior to logging in: > - If a Tails user tried to start I2P and it failed for some > reason, s/he may be advised to look in /var/log/i2p. Due to the default > umask set, the amnesia user cannot access it. > - If a Tails user (for whatever reason) decided to download an > I2P-internal torrent, any such files would be lost. > - If a Tails user wanted to set up an 'eepsite' (be it temporarily to > share something quickly or something a bit more long term once we > have persistence enabled), s/he wouldn't be able to access that > folder OK, thanks for making the usecases clear :) Let's see if and how we can support them in a reasonable way. >>A further commit reads "Add the amnesia user to the i2psvc group", >>"This will allow the standard Tails user to access the I2P config >>directory." Same question: what is it useful for? Does this *only* >>adds access to that directory, or does it gives the desktop user >>other credentials as a side effect? If access to that directory is >>really needed, and only that, perhaps we could use an ACL instead? > The only extra access /should/ be only to access that directory without > requiring admin access being set upon logging in. Has read-write access to that directory other consequence? I mean, if I understand it clearly, the proposed umask means that the desktop user has full r/w access to /var/lib/i2p/i2p-config/, so they can essentially reconfigure I2P and interfere with basically every piece of data the I2P programs trust, no? If I'm correct, we have a problem. Doesn't I2P support some config / daemon state / user data separation? >> 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? * Why not have the whole I2P thing to go over Tor? >>Also, is it possible to use the Tor SOCKS proxy, rather than going >>through polipo? (We're at the point we can almost ditch it >>entirely, and stop shipping a HTTP proxy in Tails, so adding >>a usecase for it makes me sad.) > Using a SOCKS proxy isn't possible yet but I can file a wishlist bug > for it. Yes, please. 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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Sun, 10 Nov 2013 10:41:47 + (UTC) intrigeri wrote: > Hi, > > Kill Your TV wrote (09 Nov 2013 16:33:56 GMT) : > > On Sat, 9 Nov 2013 13:28:49 + (UTC) > > intrigeri wrote: > > >>A further commit reads "Add the amnesia user to the i2psvc > >> group", "This will allow the standard Tails user to access the I2P > >> config directory." Same question: what is it useful for? Does this > >> *only* adds access to that directory, or does it gives the desktop > >> user other credentials as a side effect? If access to that > >> directory is really needed, and only that, perhaps we could use an > >> ACL instead? > > > The only extra access /should/ be only to access that directory > > without requiring admin access being set upon logging in. > > Has read-write access to that directory other consequence? Yes. If ACLs can be used there are two directories that I care about giving access to: ~i2psvc/i2p-config/eepsite/docroot ~i2psvc/i2p-config/i2psnark At the very worst we could fix it with documentation. "Set a root password if you want access to ___". I suppose my problem was thinking about this as from the PoV of the logged in user being 'trusted'. In any case I reverted the 'add to group' commit. > >> 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. > * Why not have the whole I2P thing to go over Tor? Slowness. It would be rather "painful". > >>Also, is it possible to use the Tor SOCKS proxy, rather than > >> going through polipo? (We're at the point we can almost ditch it > >>entirely, and stop shipping a HTTP proxy in Tails, so adding > >>a usecase for it makes me sad.) > > > Using a SOCKS proxy isn't possible yet but I can file a wishlist bug > > for it. > > Yes, please. Filed. 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. (Future merges will go *much* more smoothly..) signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
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 tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Sat, 16 Nov 2013 18:06:50 + (UTC) intrigeri wrote: > 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. Works for me. [..] > >> 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). IIRC there was talk about the bootstrap being done via Tor on either the Tor or tahoe lists. Removing it is fine, of course, and it's certainly not a good reason to make polipo stick around. I'll remove this as well as the 'custom' news file. signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi, Kill Your TV wrote (21 Nov 2013 02:06:30 GMT) : > intrigeri wrote: >> 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. > Works for me. Great! So a future iteration can bring back the UX improvements, without hindering security more than necessary :) 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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
intrigeri: > Kill Your TV wrote (21 Nov 2013 17:03:18 GMT) : >> service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is >> using bits of my packaging. woot. > > Congrats! I can't wait for I2P to be maintained in Debian proper... > but I'm now wondering if it's gonna be appropriate for a Debian stable > release ever. Is there a stable branch of I2P that could satisfy the > Debian stable requirements (i.e. that would only backport important > bug fixes and security fixes)? I find this most interesting as well. Is Debian policy fine with packages which likely never get into stable? (Personally, I'd be fine with a testing-only i2p package.) ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Thu, 21 Nov 2013 17:50:09 + (UTC)
intrigeri wrote:
> Hi,
>
> Kill Your TV wrote (21 Nov 2013 16:58:53 GMT) :
> > I just pushed what's likely the last of the changes for 0.22.
>
> Looks good to me, modulo a few comments:
>
> * regarding commit 95ca91a ("document the need for admin password"):
> wouldn't this be more appropriate for the end-user documentation?
> (not a blocker, just something that could be improved in the future)
>
Yeah that might be better. I can do the improvement in the future.
> * regarding commit c32cab5 ("I2P: Document ferm exceptions"): the
> HTML table seems a bit too much markup for me; how about just using
> a simple list? (not a blocker either, just nitpicking probably ;)
>
Heh..OK. I can change it to a list if that'd be preferred.
> * config/chroot_local-hooks/16-i2p_config still reads:
> # Remove the false.i2p outproxy from i2ptunnel
> # We already go out through Tor so this will never be reached
> anyway. sed -i '/^tunnel.0.proxyList/d' "$I2P/i2ptunnel.config"
> Is this still relevant? At least the comment isn't anymore,
> right?.
This one should be 'OK'. That outproxy is for visiting "clearnet"
sites and those go out through Tor because of the FoxyProxy rules.
Without the FoxyProxy rules all http://* traffic would go out via I2P
with traffic to non-I2P sites being routed to a squid proxy running at
http://false.i2p.
This change is more cosmetic than anything since that
block could be removed and nothing would be functionally different for
a Tails user. The goal of this stanza/section was to remove the
false.i2p outproxy from the I2PTunnel configuration to try to prevent
end-users that are familiar with I2P from being confused by seeing a
configured outproxy in the interface.
signature.asc
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Kill Your TV wrote (21 Nov 2013 17:03:18 GMT) : > service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is > using bits of my packaging. woot. Congrats! I can't wait for I2P to be maintained in Debian proper... but I'm now wondering if it's gonna be appropriate for a Debian stable release ever. Is there a stable branch of I2P that could satisfy the Debian stable requirements (i.e. that would only backport important bug fixes and security fixes)? 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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
adrelanos wrote (21 Nov 2013 17:46:01 GMT) : > Is Debian policy fine with packages which likely never get into stable? Yes. > (Personally, I'd be fine with a testing-only i2p package.) It's doable, but to prevent a package from going into stable, it must be dropped from testing at some (late) point of the freeze (generally thanks to a RC bug called "Should not be part of stable" or something). This implies that during the [removal from testing, stable release] time interval, we can't get official backports for the current stable release. A bit tricky (needs a careful maintainer and/or coordination with the release team), but still way better than the current state of things, if you ask me. Alternatively, another way to do it would be to 1. always keep the package out of testing (with a permanent "should not migrate to testing" RC bug, just like bitcoind has); 2. asking the Debian backports FTP masters for a general exception to be allowed to upload backports of the packages from unstable. 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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Thu, 21 Nov 2013 17:33:28 + (UTC) intrigeri wrote: > Kill Your TV wrote (21 Nov 2013 17:03:18 GMT) : > > service-wrapper-java 3.5.22, used by I2P, has landed in unstable > > and is using bits of my packaging. woot. > > Congrats! I can't wait for I2P to be maintained in Debian proper... > but I'm now wondering if it's gonna be appropriate for a Debian stable > release ever. Is there a stable branch of I2P that could satisfy the > Debian stable requirements (i.e. that would only backport important > bug fixes and security fixes)? > At the moment there isn't a stable/ESR-like branch. If there's an important bug that needs to be fixed right away there's a point release like the recent update from 0.9.8 -> 0.9.8.1. I also don't know how Debian feels about packages that "live" in testing and unstable. signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Thu, 21 Nov 2013 06:48:00 + (UTC) intrigeri wrote: > Hi, > > Kill Your TV wrote (21 Nov 2013 02:06:30 GMT) : > > intrigeri wrote: > > >> 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. > > > Works for me. > > Great! So a future iteration can bring back the UX improvements, > without hindering security more than necessary :) I just pushed what's likely the last of the changes for 0.22. signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi,
Kill Your TV wrote (21 Nov 2013 16:58:53 GMT) :
> I just pushed what's likely the last of the changes for 0.22.
Looks good to me, modulo a few comments:
* regarding commit 95ca91a ("document the need for admin password"):
wouldn't this be more appropriate for the end-user documentation?
(not a blocker, just something that could be improved in the future)
* regarding commit c32cab5 ("I2P: Document ferm exceptions"): the
HTML table seems a bit too much markup for me; how about just using
a simple list? (not a blocker either, just nitpicking probably ;)
* config/chroot_local-hooks/16-i2p_config still reads:
# Remove the false.i2p outproxy from i2ptunnel
# We already go out through Tor so this will never be reached anyway.
sed -i '/^tunnel.0.proxyList/d' "$I2P/i2ptunnel.config"
Is this still relevant? At least the comment isn't anymore, right?
* I don't get why don't we would now want to install
/usr/share/i2p/router.config with a chroot_local-includes anymore.
AFAIK that would be the only occurrence thereof in the Tails build
system. IMHO present and future changes to this file would be easier
to follow this way, than by writing this file with a hook.
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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
service-wrapper-java 3.5.22, used by I2P, has landed in unstable and is using bits of my packaging. woot. http://ftp-master.metadata.debian.org/changelogs//main/s/service-wrapper-java/service-wrapper-java_3.5.22-1_changelog signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Kill Your TV wrote (21 Nov 2013 19:20:32 GMT) :
>> * regarding commit c32cab5 ("I2P: Document ferm exceptions"): the
>> HTML table seems a bit too much markup for me; how about just using
>> a simple list? (not a blocker either, just nitpicking probably ;)
>>
> Heh..OK. I can change it to a list if that'd be preferred.
Yes, please (but you can save it for a future iteration, let's get
the rest ready to merge first).
>> * config/chroot_local-hooks/16-i2p_config still reads:
>> # Remove the false.i2p outproxy from i2ptunnel
>> # We already go out through Tor so this will never be reached
>> anyway. sed -i '/^tunnel.0.proxyList/d' "$I2P/i2ptunnel.config"
>> Is this still relevant? At least the comment isn't anymore,
>> right?.
> This one should be 'OK'. That outproxy is for visiting "clearnet"
> sites and those go out through Tor because of the FoxyProxy rules.
> Without the FoxyProxy rules all http://* traffic would go out via I2P
> with traffic to non-I2P sites being routed to a squid proxy running at
> http://false.i2p.
> This change is more cosmetic than anything since that
> block could be removed and nothing would be functionally different for
> a Tails user. The goal of this stanza/section was to remove the
> false.i2p outproxy from the I2PTunnel configuration to try to prevent
> end-users that are familiar with I2P from being confused by seeing a
> configured outproxy in the interface.
OK, makes sense, thanks for clarifying. So, only the code comment
needs an update, cool.
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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Fri, 22 Nov 2013 20:57:46 + (UTC)
intrigeri wrote:
> Kill Your TV wrote (21 Nov 2013 19:20:32 GMT) :
> >> * regarding commit c32cab5 ("I2P: Document ferm exceptions"): the
> >> HTML table seems a bit too much markup for me; how about just
> >> using a simple list? (not a blocker either, just nitpicking
> >> probably ;)
> >>
>
> > Heh..OK. I can change it to a list if that'd be preferred.
>
> Yes, please (but you can save it for a future iteration, let's get
> the rest ready to merge first).
OK
[..]
> > This change is more cosmetic than anything since that
> > block could be removed and nothing would be functionally different
> > for a Tails user. The goal of this stanza/section was to remove the
> > false.i2p outproxy from the I2PTunnel configuration to try to
> > prevent end-users that are familiar with I2P from being confused by
> > seeing a configured outproxy in the interface.
>
> OK, makes sense, thanks for clarifying. So, only the code comment
> needs an update, cool.
AFK stuff got in the way, hence the delay.
Anyhow...I think the issues have been addressed in my branch.
signature.asc
Description: PGP signature
___
tails-dev mailing list
tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Hi, Kill Your TV wrote (29 Nov 2013 21:50:31 GMT) : > Anyhow...I think the issues have been addressed in my branch. Merged into devel, imported the i2p source package and the 3 binary packages it produces. Note that I have *not* imported the new service-wrapper from your APT repository: * it's not made it out of unstable yet * there is no indication in the i2p package's dependencies that the version we're currently installing from Wheezy (3.5.3+repack-0+nmu1) isn't good enough for it * the only explanation I've seen for this upgrade is the support of the umask feature, that we are not using eventually ... so I've prioritized stability (less changes) over getting the latest and shiniest stuff. Once service-wrapper migrates to testing, if needed we can upload it to wheezy-backports and install from there. 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] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
On Sat, 30 Nov 2013 12:00:29 + (UTC) intrigeri wrote: > Hi, > > Kill Your TV wrote (29 Nov 2013 21:50:31 GMT) : > > Anyhow...I think the issues have been addressed in my branch. > > Merged into devel, imported the i2p source package and the 3 binary > packages it produces. > > Note that I have *not* imported the new service-wrapper from your APT > repository: [..] That's perfectly fine. > > Once service-wrapper migrates to testing, if needed we can upload it > to wheezy-backports and install from there. This is also fine, of course. It may be good to have the new one but probably not essential. I package whatever we're shipping in the upstream I2P bundles for Linux, Windows, OSX, etc. but old versions of the wrapper should "just work". Cheers (and TY), kytv signature.asc Description: PGP signature ___ tails-dev mailing list tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev
Re: [Tails-dev] Reviewing kytv:feature/i2p-0.9.8.1 [Was: about the maintenance of I2P in Tails]
Kill Your TV wrote (30 Nov 2013 16:48:21 GMT) : > Cheers (and TY), Thank *you*! 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
