Re: [Tails-dev] [review'n'merge 1.1.1] I2P boot parameter, …

Delete this message

Reply to this message
Author: Kill Your TV
Date:  
To: tails-dev
Subject: Re: [Tails-dev] [review'n'merge 1.1.1] I2P boot parameter, firewall rules, etc.
On Sat, 2 Aug 2014 13:51:06 +0000 (UTC)
intrigeri <intrigeri@???> wrote:

[...]

>
> > +# Let's make sure that *just* the "i2psvc" user has access to the
> > I2P files +chown -R i2psvc:i2psvc /usr/share/i2p
> > +find /usr/share/i2p -type f \( -name '*.jar' -o -name '*.war' \)
> > -print0 | xargs -r -0 chmod 640
>
> It's unclear to me what doing this buys us.


The intention was to enforce that, "no, you can't even start I2P from
the command line as the anmesia user by using `java -cp $CLASSPATH
[args]`"

Considering the firewall rules, it's overkill.

> > +mv -f /usr/share/i2p "$DEST"
> > +mv -f /usr/sbin/wrapper "$DEST/i2p"
> > +mv -f /usr/share/applications/i2p.desktop "$DEST/i2p"
>
> I'm a little bit concerned that we're mixing, in $DEST/i2p, any
> content that came from /usr/share/i2p with content that comes from
> other places, which feels fragile. E.g. if a "wrapper" file appears
> someday in /usr/share/i2p, then this will break. I recommend instead
> setting DEST=/usr/share/tails/i2p-disabled and moving everything
> in there.


Ack.

> > +    chmod 644 /etc/sudoers.d/zzz_i2p

>
> The convention for files in that directory is 0440 instead.


Ack.


> > +Starting with Tails v1.1.1, I2P is not enabled by default when
> > Tails starts.
>
> "Tails 1.1.1" would be more consistent with how we do it
> everywhere else.


Ack.

> Thanks for thinking of updating the design doc! I've some nitpicking
> to do about it, though:
>
> > +Starting with Tails v1.1.1, I2P is not enabled by default when
> > Tails starts. +In order to use I2P, add the <span
> > class="command">i2p</span> boot option +to the <span
> > class="application">boot menu</span>. For detailed +instructions,
> > see the documentation on [[using the <span
> > +class="application">boot
> > menu</span>|first_steps/startup_options#boot_menu]].
>
> This phrasing looks adequate for end-user doc, but not for design
> documentation. I suggest e.g. "a user must add [...]" instead.
>
> Also, this section should point to the files that implement the new
> disabling/re-enabling system, firewall rules handling, etc. I think
> contribute/design/Tor_enforcement/Network_filter.mdwn needs an update
> too. And design/I2P


Ack

> Regarding the firewall rules:
>
> Why does i2psvc need direct access to Tor's DNSPort?
>
> >                  daddr 127.0.0.1 proto tcp syn mod multiport
> > destination-ports (2827 4444 4445 6668 7656 7657 7658 7659 7660
> > 8998) {
> > -                    mod owner uid-owner amnesia ACCEPT;
> > +                    @if $use_i2p mod owner uid-owner (amnesia
> > i2psvc) ACCEPT;
> > +                }

>
> I suspect that i2psvc doesn't need access to *all* of these ports.
> That's certainly not a blocker for merging this branch, but maybe
> it's worth creating a Research ticket about it?


I'll investigate and incorporate my findings in an upcoming merge
request.

> > Other changes: 
> >   - plugins will be disabled within I2P. Plugins, without
> > persistence aren't very useful. Now that I know the switch to
> > disable them, let's do it. (Users that want to use them can easily
> > enable them)
> >   - documentation updates (more to come, but maybe not for these
> >     changes?)
> >   - the webmail app is changed to keep emails on the mail server.
> >     The default setting was changed upstream to store emails
> >     locally.(I'm submitting this one since it's low risk for Tails
> > and it greatly improves user experience/expectations). This change
> >     depends on I2P 0.9.14 or newer. A point release (0.9.14.1)
> > should be ready a few days before the Tails freeze.

>
> I would usually ask separate branches for such unrelated changes, but
> all of this makes sense to me, so let's cut on the paperwork for this
> time :)


Ack. I wasn't sure how much added work would be added to your
(= $TAILS_DEVS) plate, but I certainly don't mind using separate
branches.

>
> > If these changes are acceptable, please consider them for inclusion
> > in the upcoming 1.1.1 release. Is there anything else that is
> > desirable with respect to I2P & 1.1.1?
>
> > (I presume that the separate browser will be too much for a point
> > release,
>
> Not necessarily, but let's polish and merge this initial branch first,
> and then we'll see how much time we've left until the freeze :)


All right. I doubt I'll be able get that into a "reviewable state"
within the next few days, but we'll see if "IRL/AFK time/events" allow
it.


--
GPG ID: 0x5BF72F42D0952C5A
Fingerprint: BD12 65FD 4954 C40A EBCB F5D7 5BF7 2F42 D095 2C5A