- the I2P Browser.
- monitoring of the I2P bootstrapping process => notify users about its progress or failures.
- the pre-configured Pidgin account for Irc2P.
- configuring I2P itself to be in “Hidden mode” (i.e. don’t be a relay) since the way Tails often is used (no persistence, abrupt shutdown) otherwise would leave dead relays on the network, hurting its performance.
- AppArmor profile for I2P.
Let’s call this person the Tails-I2P liaison. This person will need solid general Linux skills, as well as decent knowledge of I2P. Yeah, that’s vague, but let’s say that if you look at the diff of the removal of I2P and don’t get scared (possibly excluding the stuff under the
features directory, which is our automtaed test suite), you probably have what it takes. anonym will mentor this person about Tails development (e.g. building images will be a requirement for the liaison’s tasks).
The Tails-I2P liaison’s jobs are:
- to test new I2P releases in Tails:
- let us know when we should import the I2P package (i.e. when tests are good).
- provide us with patches for any changes needed (e.g. new feastures/preferences/etc).
- in general improve the I2P-integration in Tails.
- And for the actual reintroduction we also want to be shown work and commitment that gives us hope that this effort will be kept maintained for a long time, and not abandoned shortly after the first few releases where I2P has been reintroduced. What I’d prefer to see here is:
- Tails Greeter option for enabling I2P
- a solution for Bug #8280
- fixing the I2P bootstrapping monitoring: there is a
wait_until_i2p_builds_a_tunnelwhich I find quite unacceptable. I don’t even recall the specifics about this issue, and sadly we do not have a ticket, so an investigation of why we ended up having to do this will be required.
(When it comes to the Deiban packaging, it is currently done by zzz, the I2P Project Manager. zzz ideally does not want to be the Debian package maintainer, but the Tails-I2P liaison does not necessarily have to be the replacement — that could be yet another person. Rationale: probably it will be easier to separate these responsibilities so the required skill-sets will be smaller.)
Step one to start working on this would be:
- checkout a new Git branch
- revert commit:e9d02049b4086b3516224227dbb6d4c73f8ff159
- add the
deb.i2p2.deAPT repo during the build, so I2P can be installed from there, since we don’t have the packages in our repos any more.
- start hacking!
Related to Tails -
|Blocks Tails - Bug #11114: I2P tests are fragile||Confirmed||2016-02-13|
|Blocks Tails - Bug #11452: "I2P displays a notice when bootstrapping fails" test is fragile||Confirmed||2016-05-20|
|Blocks Tails - Bug #11462: "I2P is running" test is fragile: may fail when the time has not sync'ed yet||Confirmed||2016-05-23|
|Blocks Tails - Feature #7724: Sandbox I2P||Confirmed||2015-11-17|
|Blocks Tails - Feature #5544: Persistence preset: I2P||Confirmed|
|Blocked by Tails - Feature #16531: Define our core code base||In Progress||2019-03-05|
#5 Updated by vk 2017-05-04 12:26:28
I did start some work on this (see https://mailman.boum.org/pipermail/tails-dev/2017-May/011409.html for details).
There’re some questions in the thread above regarding Bug #8280, as soon as I get some guidance on those - I will send a patch for review.
#7 Updated by vk 2017-05-04 18:40:02
> Stop shoving i2p down our throats! We don’t want it and no one uses it. Stop wasting our RAM with this bloat.
Hello, my friend, nice to see you too. before posting to tails-dev@, and in this ticket I did some research in this bugtracker and I2P Trac, and know that I2P has a rough history in Tails.
Unfortunately I fail to see the whole I2P issue takes too much of your RAM, so may I? Thanks.
To make it clear for those who don’t want to follow the URL: I’m eager to pick up I2P testing, integration, and Debian packaging tasks to get I2P back to Tails. If I’m too late, and the decision was made somewhere to drop I2P forever - please close/reject this ticket with appropriate comment.
Otherwise - let’s continue meaningful discussion; I will also be contacting zzz to sync up with him/her on this, he was heavily involved before according to
#14 Updated by anonym 2017-12-30 17:06:02
- Assignee set to mhatta
- Target version set to Tails_3.9
At 34c3 I met with zzz and mhatta, the Debian package maintainer of the I2P package in Debian. mhatta intends to do the work needed to reintroduce I2P into Tails, and is committed to maintain the I2P-integration in Tails for the foreseeable future. Yay!
Our current goal is to reintroduce it with the improvements listed in this ticket’s description in the Tails 3.9 release (or whatever we call the release happening on 2018-08-28).
#21 Updated by mhatta 2018-12-22 01:05:30
Finally, I began some work on reintroducing I2P into Tails. My repo is: https://gitlab.com/masayukihatta/tails/tree/feature/12264-reintroduce-i2p
The first problem I encountered is the official I2P apt repo only provides https. Tails won’t support https transport (https://redmine.tails.boum.org/code/issues/8143).
#22 Updated by mhatta 2018-12-23 06:02:52
- File failed.log.bz2 added
- % Done changed from 0 to 10
I found there is still http://deb.i2p2.no/ (not .de), so I could add and install I2P tentatively.
Somehow the build fails, and I can’t find out why. Any hints?
Here’s log of “rake —trarce build”. It goes well without I2P (ok.log).
#24 Updated by anonym 2018-12-23 13:31:55
It looks to me as if the builder VM started running out of RAM an OOM killed the
mksquashfs process. I can see you are doing an in-RAM build, and the amount of build space we specify is pretty close to the actual minimum, so it makes sense that the extra space required by installing I2P cause issues.
Enabling more build space is just a matter of:
--- a/vagrant/lib/tails_build_settings.rb +++ b/vagrant/lib/tails_build_settings.rb @@ -10,7 +10,7 @@ VIRTUAL_MACHINE_HOSTNAME = 'vagrant-stretch' VM_MEMORY_BASE = 1024 # Approximate amount of extra space needed for builds -BUILD_SPACE_REQUIREMENT = 12*1024 +BUILD_SPACE_REQUIREMENT = 13*1024 # Virtual machine memory size for on-disk builds VM_MEMORY_FOR_DISK_BUILDS = VM_MEMORY_BASE
#29 Updated by sajolida 2019-08-21 18:07:53
I had a chat with some people from I2P today to discuss whether we want to reintroduce I2P in Tails and what it would take.
Even if the I2P developers do all the work they can on their side to make I2P “Tails-ready”, reintroducing I2P in Tails will have a cost for us:
- Integration work that they won’t be able to do themselves: test suite, Tails Greeter, etc.
- Non-coding work that they won’t be able to do themselves: UX, doc, help desk, translations, etc.
- Maintenance cost. We’ve already removed I2P once from Tails because of maintenance issues.
- UX cost: more options means more things for our users to understand, more choice to make, and more confusion and errors. Keeping software limited and focus in the features it offers is a virtue. The opposite is a problem called feature creep: https://en.wikipedia.org/wiki/Feature_creep.
Exciting news from I2P:
- Someone told them that I2P works in China in places where Tor is blocked. Though China has tried to block access to some aspects of I2P, it’s still work in some places.
- I2CP (I hope I got the acronym right) has obfuscation properties similar to obfs4 that might help some people circumvent censorship. We should check whether these properties could also benefit the PT community in general or are specific to I2P.
I told the I2P folks that we would make a decision regarding a possible inclusion of I2P in Tails as part of the discussion that we will have on Feature #16531. Until then, we should stop sending them mixed signals: it’s not clear yet whether we want I2P back in Tails or not.
#30 Updated by Anonymous 2019-10-09 18:30:29
Tails should not underestimate his influence on some userbases.
During the last months where a big amount of hidden services were (and still are) getting harsh DDoS attacks with the INTRODUCE2_CELL scheme there often was the idea from various sides to switch to I2P.
Some tried and failed hard because the userbase went to zero.
Many users who visit hidden services only trust and use Tails as the OS of choice to browse anonymously and uncensored.
I think if Tails would reintroduce I2P that would be a big benefit.
Maybe the influence wouldnt be seen directly but especially the last months showed that having an anonymous and uncensorable working backup network to Tor could get important again.
But with the current style Tails is not ready for using it with I2P.
There is a workaround but installing I2P in Tails currently is difficult and unsupported.
So if a user trust into Tails they are sticked to Tor.
And its working the other way round too. If the Tails userbase would get a little bit more familiar with I2P then i think I2P would see a few users more because maybe some hidden services would went into I2P.
Its the electro car - power socket problem. (I am pretty sure there is a real word for what i mean.)
I2P was removed from Tails because of less userbase and the users will not come back because they are now glued to Tor because of the decision to remove I2P.
I dont know how costly it is (or if there even is someone who would like to spend time on reintroducing I2P but maybe dont get the feedback that its important) to reintroduce I2P and if its not worth it i can understand the decision but for diversity it would be important to reintroduce I2P and the current INTRODUCE2 DDoS attacks confirm that.
#31 Updated by intrigeri 2019-10-09 18:38:24
> I2P was removed from Tails because of less userbase
FTR, this is incorrect. Here’s why we removed I2P:
tails (2.12) unstable; urgency=medium * Major changes - Completely remove I2P. :( We have decided to remove I2P (see <del><a class='issue tracker-1 status-3 priority-5 priority-default closed child' href='/code/issues/11276' title='Decide what to do wrt. I2P'>Bug #11276</a></del>) due to our failure of finding someone interested in maintaining it in Tails (Closes: <del><a class='issue tracker-2 status-3 priority-4 priority-default closed child' href='/code/issues/12263' title='Remove I2P'>Feature #12263</a></del>).