Bug #11276

Decide what to do wrt. I2P

Added by intrigeri over 1 year ago. Updated 6 months ago.

Status:ResolvedStart date:03/23/2016
Priority:ElevatedDue date:
Assignee:-% Done:

100%

Category:-
Target version:Tails_2.11
QA Check:Pass Blueprint:
Feature Branch: Easy:
Type of work:Communicate Affected tool:I2P

Description

... depending on if/how its integration into Tails, and the corresponding Debian packages, are maintained.

I2P 0.9.25 is a simple bugfix release, we can skip it if needed. I2P 0.9.26 should be out at the end of May, and we probably should have in Tails 2.4 if we're going to keep I2P.


Related issues

Related to Tails - Feature #12263: Remove I2P Resolved 02/25/2017
Related to Tails - Feature #12264: Reintroduce I2P Confirmed 02/25/2017
Blocked by Tails - Feature #11672: Compute stats about how much I2P is used in Tails Resolved 08/20/2016
Blocks Tails - Feature #12102: Check I2P maintainers' plans to get it into Debian proper Rejected 01/01/2017
Blocks Tails - Bug #12108: I2P fails to start on Stretch Rejected 01/02/2017

Associated revisions

Revision e9d02049
Added by anonym 6 months ago

Completely remove I2P.

We have decided to remove I2P (Refs: #11276) due to our failure of
finding someone interested in maintaining it in Tails.

Will-fix: #12263

History

#1 Updated by anonym over 1 year ago

I managed to import 0.9.25 without issue, which is a good sign for the Debian packaging. Combined with pr0ng as an I2P-Tails liaison, I think we're good, but let's wait and see how I2P 0.9.26 vs Tails 2.4 fares before closing this ticket.

#2 Updated by intrigeri over 1 year ago

I managed to import 0.9.25 without issue, which is a good sign for the Debian packaging. Combined with pr0ng as an I2P-Tails liaison, I think we're good, but let's wait and see how I2P 0.9.26 vs Tails 2.4 fares before closing this ticket.

It sounds like you mean that having a maintained (third-party) I2P Debian package is good enough to close this ticket. I wonder if that's enough. Who's going to maintain the integration of I2P into Tails? Is pr0ng supposed to take it over as well?

#3 Updated by anonym about 1 year ago

  • Assignee changed from anonym to intrigeri
  • QA Check set to Info Needed

intrigeri wrote:

I managed to import 0.9.25 without issue, which is a good sign for the Debian packaging. Combined with pr0ng as an I2P-Tails liaison, I think we're good, but let's wait and see how I2P 0.9.26 vs Tails 2.4 fares before closing this ticket.

It sounds like you mean that having a maintained (third-party) I2P Debian package is good enough to close this ticket. I wonder if that's enough.

There's no 3rd party packaging involved. Tails 0.9.25 was packaged by zzz, one of the core I2P developers.

Who's going to maintain the integration of I2P into Tails? Is pr0ng supposed to take it over as well?

That would be pr0ng, yes.

Your the "as well" seems to indicate that you thought pr0ng would do the packaging. That was also his/her understanding earlier (might have been posted to tails-dev@) so I do not blame you, but this has since gotten cleared up: we will only use the normal, official Debian packages, as always, and pr0ng will act as a liaison, creating an import-style tickets when new package become available and informing us about changes in I2P affecting us. Most of the time pr0ng can probably send us a pull-request for the changes needed, but perhaps not for stuff requiring more complex knowledge of Tails, e.g. the I2P persistence option.

#4 Updated by intrigeri about 1 year ago

  • Assignee changed from intrigeri to anonym

There's no 3rd party packaging involved. Tails 0.9.25 was packaged by zzz, one of the core I2P developers.

Sure, I got that :) Just to clarify: by "3rd party package" I meant one that is not in Debian, i.e. one for which we have to rely on another source for packaging, maintenance, security updates etc. At some point I made it clear that this was not a satisfying situation for me on the long term, and kytv filed an ITP bug in Debian, but we're still handling I2P as if it were special, which does add some maintenance cost on our side (and that's really an exceptions, generally we insist on stuff being in Debian before we include it in Tails).

Who's going to maintain the integration of I2P into Tails? Is pr0ng supposed to take it over as well?

That would be pr0ng, yes.

Your the "as well" seems to indicate that you thought pr0ng would do the packaging. That was also his/her understanding earlier (might have been posted to tails-dev@) so I do not blame you, but this has since gotten cleared up: we will only use the normal, official Debian packages, as always, and pr0ng will act as a liaison, creating an import-style tickets when new package become available and informing us about changes in I2P affecting us. Most of the time pr0ng can probably send us a pull-request for the changes needed, but perhaps not for stuff requiring more complex knowledge of Tails, e.g. the I2P persistence option.

OK. So, for example: we should start reassigning to pr0ng any important I2P ticket we have open, right? E.g. #7724 has been WIP for 2 years now, and I raised concerns about how it went 4 months ago; and #8280 is an important 1y old UX follow-up to the introduction of the I2P browser, with little progress so far; that's what I call maintaining the integration of I2P into Tails :)

#5 Updated by anonym about 1 year ago

  • Target version changed from Tails_2.4 to Tails_2.5

I asked pr0ng to register an account a while ago, and have done so again + pointed him/her to this ticket for clarification. I don't think we can proceed in the positive sense (e.g. keeping I2P in Tails) without that. Postponing, also.

#6 Updated by intrigeri about 1 year ago

I asked pr0ng to register an account a while ago, and have done so again + pointed him/her to this ticket for clarification. I don't think we can proceed in the positive sense (e.g. keeping I2P in Tails) without that.

ACK

#7 Updated by anonym about 1 year ago

anonym wrote:

I asked pr0ng to register an account a while ago, and have done so again + pointed him/her to this ticket for clarification. I don't think we can proceed in the positive sense (e.g. keeping I2P in Tails) without that. Postponing, also.

So I talked briefly with zzz and have some news/clarifications:

  • probably we'll just miss out on i2p 0.9.26 given our respective release timings. oh well.
  • zzz will continue to package i2p until a suitable replacement is found
  • zzz and has made major improvements in the i2p packaging (e.g. "unbundling external packages and adding dependencies for them")
  • the above point is part of a slow but steady process of getting the i2p packages in shape for inclusion in Debian proper, yay!
  • they haven't heard of pr0ng for a month (!) and if this drags out they'll look for yet another replacement... so we're back on square one here possibly.

#8 Updated by intrigeri about 1 year ago

  • zzz and has made major improvements in the i2p packaging (e.g. "unbundling external packages and adding dependencies for them")
  • the above point is part of a slow but steady process of getting the i2p packages in shape for inclusion in Debian proper, yay!

Lovely to read this! :)

  • they haven't heard of pr0ng for a month (!) and if this drags out they'll look for yet another replacement... so we're back on square one here possibly.

Oops :/

#9 Updated by BitingBird about 1 year ago

  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

#10 Updated by intrigeri about 1 year ago

  • Target version changed from Tails_2.5 to Tails_2.6

I hope we have enough info to make a decision at the summit in August.

#11 Updated by intrigeri about 1 year ago

So, I2P 0.9.26 was released on June 7: https://geti2p.net/en/blog/post/2016/06/07/0.9.26-Release. AFAIK nobody got in touch with us to coordinate the upgrade in Tails. That release apparently does not fix important security issues, so it's no big deal that we've missed it for Tails 2.5. But still it's not reassuring wrt. the state of the I2P/Tails liaison.

#12 Updated by anonym about 1 year ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 10 to 100
  • QA Check deleted (Info Needed)

A new maintainer has stepped up, so let's consider this resolved with the answer: let's keep I2P.

#13 Updated by intrigeri about 1 year ago

  • Status changed from Resolved to In Progress
  • Assignee set to intrigeri
  • Target version changed from Tails_2.6 to Tails_2.9.1
  • % Done changed from 100 to 50

A new maintainer has stepped up, so let's consider this resolved with the answer: let's keep I2P.

Sure, but we need to reconsider in December. We have nothing else than this ticket to track that, so recycling it.

#14 Updated by intrigeri 11 months ago

I've pinged zzz and icu812 today (one month about my initial report, that has not been replied yet) about a problem with their APT repo that prevents us from including I2P on the branch for #8183. Fingers crossed.

#15 Updated by intrigeri 10 months ago

A month later, no reply => pinged them again.

#16 Updated by intrigeri 10 months ago

  • Blocked by Feature #11672: Compute stats about how much I2P is used in Tails added

#17 Updated by intrigeri 10 months ago

According to my records, nothing has moved since a potential new maintainer volunteered 3 months ago, and we never got any answer to our email and pings. I'm fine with waiting one more month, as decided (the deadline we've set was fixing #8280 and #10890 in Tails 2.8, i.e. December 13 and I guess a freeze near the end of November). But perhaps we should start looking for other options, like raising this issue on tails-dev@ and Twitter (or even a blog post?), asking for people who want to keep I2P in Tails to volunteer? anonym, what do you think?

#18 Updated by intrigeri 10 months ago

Data point: #11672 tells us than less than 1.7% of the bug reports we receive are from users with I2P enabled.

#19 Updated by anonym 10 months ago

intrigeri wrote:

Data point: #11672 tells us than less than 1.7% of the bug reports we receive are from users with I2P enabled.

While I don't find the number surprising if it were true, I'm sure there's a lot of bias here and I don't think we should rely on these numbers for actual decisions. For instnace, I can imagine that someone that normally uses Tails with I2P, which has detected a bug which they want to report, would reboot Tails into as clean a state as possible (no persistence, I2P etc) when doing the whisperback report.


In other news, it turns out that we have email communication problems with the new Tails+I2P maintainer, and emails have been dropped, and that's why the new maintenance effort of I2P has failed. I have proposed that until that is resolved, me and him/her can communicate privately over email for things that do not fit redmine. And I have asked the new maintaner to post something to this ticket, so let's see...

#20 Updated by sajolida 10 months ago

While I don't find the number surprising if it were true, I'm sure
there's a lot of bias here and I don't think we should rely on these
numbers for actual decisions.

Unfortunately, that's the only data that we have. Does I2P have usage
metrics like Tor does?

What I'm worried here is that having us put lots and time and effort in
the wrong place. Finding maintainers for I2P has been an ongoing
challenge for years. So far we've been contacting the I2P team directly,
which is probably the most technically and organizationally capable
group to handle such a thing. Seeing the past dynamics around I2P in
Tails and seeing now such a number (however imperfect it might be), I'm
not sure we should put much effort into finding other maintainers
elsewhere if the I2P team cannot provide one.

#21 Updated by cypherpunks 10 months ago

Is there a vetting process of these i2p maintainers? The i2p dev team seem to give it to whoever comes along first. Tails should be wary of that.

#22 Updated by anonym 10 months ago

sajolida wrote:

While I don't find the number surprising if it were true, I'm sure
there's a lot of bias here and I don't think we should rely on these
numbers for actual decisions.

Unfortunately, that's the only data that we have. Does I2P have usage
metrics like Tor does?

There's http://stats.i2p at least.

What I'm worried here is that having us put lots and time and effort in
the wrong place.

For the record, I share this worry. I just don't think there are any stats we can get reliable answers from.

Finding maintainers for I2P has been an ongoing
challenge for years. So far we've been contacting the I2P team directly,
which is probably the most technically and organizationally capable
group to handle such a thing. Seeing the past dynamics around I2P in
Tails and seeing now such a number (however imperfect it might be), I'm
not sure we should put much effort into finding other maintainers
elsewhere if the I2P team cannot provide one.

Agreed! If they cannot find one, we have to give up on it.

cypherpunks wrote:

Is there a vetting process of these i2p maintainers? The i2p dev team seem to give it to whoever comes along first. Tails should be wary of that.

Like any other contributions, even from other "core" Tails contributors, the ones we receive about I2P will go through our review process.

#23 Updated by intrigeri 10 months ago

Like any other contributions, even from other "core" Tails contributors, the ones we receive about I2P will go through our review process.

… but the I2P packages can ship basically whatever they want, as long as it's in a safe-list of directories where we expect them to ship stuff.

#24 Updated by intrigeri 9 months ago

  • Assignee changed from intrigeri to anonym

Next step is probably to set (and communicate) a new deadline, since it's now obvious that the one we set previously can't be met, mostly due to the communication being broken and no alternate ways of communication being tried. I'll let anonym handle this.

#25 Updated by intrigeri 9 months ago

I propose that the deadline for the work we already agreed upon is: in time for Tails 2.12 (April 18); given that will be branches submitted by a new contributor, let's be realistic, a few roundtrips will be needed, so the branches shall be submitted no longer that at the end of February. This gives them 3 more months, on top of the month that has already gone since communication was re-established (at least with anonym, and hopefully with the rest of us if i2pmail.org has dealt with their problems). I think that's the nicest we can reasonably be.

Of course, this deadline assumes that the I2P package will be well maintained meanwhile, to allow us to import any fix to serious problems. Otherwise, we might have to drop it earlier.

anonym, what do you think? If you agree, can you communicate this to I2P folks ASAP? Or shall I do it? I really don't want the deadline to be pushed again merely because we fail to communicate it to them early enough.

#26 Updated by anonym 8 months ago

  • Target version changed from Tails_2.9.1 to Tails 2.10

#27 Updated by anonym 8 months ago

intrigeri wrote:

Like any other contributions, even from other "core" Tails contributors, the ones we receive about I2P will go through our review process.

… but the I2P packages can ship basically whatever they want, as long as it's in a safe-list of directories where we expect them to ship stuff.

Yes, but the I2P packages are prepared by zzz. The I2P Debian packager and whoever is gonna help maintain I2P in Tails is not necessarily the same person, even though I've heard zzz want to outsource the Debian packaging at some point -- whenever that happens I'm confident they will establish trust in this person first.

I propose [...]
anonym, what do you think? If you agree, can you communicate this to I2P folks ASAP? Or shall I do it? I really don't want the deadline to be pushed again merely because we fail to communicate it to them early enough.

I'll talk to zzz in person at 33c3.

#28 Updated by intrigeri 8 months ago

I propose [...]
anonym, what do you think? If you agree, can you communicate this to I2P folks ASAP? Or shall I do it? I really don't want the deadline to be pushed again merely because we fail to communicate it to them early enough.

I'll talk to zzz in person at 33c3.

Excellent!

#29 Updated by anonym 8 months ago

I've talked to zzz now and we decided/established this:

  • zzz will start to look around for the new Tails-I2P liaison ASAP, now with all requirements clear from the start. Solid Linux skills + knowledge of I2P should be enough -- I'll mentor this person about Tails development (e.g. building images will be a requirement for the liaison's tasks). If/when one is found, they'll immediately contact me privately (working around the i2pmail.org vs boum.org spam issue) and register an account on our bug tracker, and we'll establish a workflow based on those channels.
  • If no new Tails-I2P liaison has been found before mid-February, zzz and me will reevaluate the situation. That probably means they continue their search, but we rip I2P out of Tails for the time being. We'll reintroduce it once a liaison has been found, and s/he has a Tails branch where I2P integration has been put into a good state again.
  • I'll keep on importing + testing I2P packages prepared by zzz until we've found the Tails-I2P liaison -- this person will take over the testing part, but I will be the one that imports packages.
  • 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 there are two medium-pressure roles instead of one high-pressure role. And the required skill-sets will be smaller, respectively. Also, it avoids a bit the single-point of failure issue like we had with kytv.
  • So, just to be extra clear, the Tails-I2P liaison's jobs are:
    • to test new I2P releases in Tails and provide us patches for any changes needed, and
    • in general improve the I2P-integration in Tails (e.g. #8280 and other I2P-related tickets).
  • If/when the Tails-I2P liaison's has put the I2P-integration in good shape, we introduce a Greeter option to enable I2P in Tails (instead of the kernel cmdline) in order to promote it to our users a bit more.

#30 Updated by intrigeri 8 months ago

  • Target version changed from Tails 2.10 to Tails_2.11

Good.

  • zzz will start to look around for the new Tails-I2P liaison ASAP, now with all requirements clear from the start. Solid Linux skills + knowledge of I2P should be enough -- I'll mentor this person about Tails development (e.g. building images will be a requirement for the liaison's tasks).

Indeed, some of the tasks that are included in the requirements we defined are integration ("glue") ones, and the job definition is mostly about that.

If/when one is found, they'll immediately contact me privately (working around the i2pmail.org vs boum.org spam issue) and register an account on our bug tracker, and we'll establish a workflow based on those channels.

OK. I'm not convinced that it's sustainable to have a liaison person who's not able to communicate on our mailing lists, but this will do for the time being :)

  • If no new Tails-I2P liaison has been found before mid-February, zzz and me will reevaluate the situation. That probably means they continue their search, but we rip I2P out of Tails for the time being. We'll reintroduce it once a liaison has been found, and s/he has a Tails branch where I2P integration has been put into a good state again.

ACK. Setting the corresponding target version, then.

  • I'll keep on importing + testing I2P packages prepared by zzz until we've found the Tails-I2P liaison -- this person will take over the testing part, but I will be the one that imports packages.

Sounds good.

  • 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 there are two medium-pressure roles instead of one high-pressure role. And the required skill-sets will be smaller, respectively. Also, it avoids a bit the single-point of failure issue like we had with kytv.

Full ACK.

  • If/when the Tails-I2P liaison's has put the I2P-integration in good shape, we introduce a Greeter option to enable I2P in Tails (instead of the kernel cmdline) in order to promote it to our users a bit more.

IMO it is part of the liaison person's job to integrate it in the Greeter, possibly with some mentoring. I mean, I'm fine if anyone else wants to help and do it on their free time, but IMO it's definitely not something we should feel compelled to do, and it's not part of our Core budget (e.g. Foundations Team).

#31 Updated by intrigeri 8 months ago

  • Blocks Feature #12102: Check I2P maintainers' plans to get it into Debian proper added

#32 Updated by intrigeri 8 months ago

  • Blocks Bug #12108: I2P fails to start on Stretch added

#33 Updated by anonym 6 months ago

  • Assignee changed from anonym to intrigeri
  • QA Check set to Info Needed

intrigeri wrote:

  • If no new Tails-I2P liaison has been found before mid-February, zzz and me will reevaluate the situation. That probably means they continue their search, but we rip I2P out of Tails for the time being. We'll reintroduce it once a liaison has been found, and s/he has a Tails branch where I2P integration has been put into a good state again.

ACK. Setting the corresponding target version, then.

zzz actually introduced me to a potential Tails-I2P liaison, but despite some pings I have not heard anything back. And dow it's late mid-February. So, let's reevaluate: my position is that we remove I2P in Tails 2.12. I feel the string of failures on this front is a good enough explanation. Sad but true.

IMHO we should announce this ASAP on our blog, or at least on Twitter, which might attract someone to step up to reintroduce I2P into Tails.

If you agree, intrigeri, I think we can just go ahead and do this. In that case I volunteer to do the work.

#34 Updated by intrigeri 6 months ago

  • Assignee changed from intrigeri to anonym

my position that we remove I2P in Tails 2.12.

ACK

IMHO we should announce this ASAP on our blog, or at least on Twitter, which might attract someone to step up to reintroduce I2P into Tails.

If you agree, intrigeri, I think we can just go ahead and do this. In that case I volunteer to do the work.

Yes ⇒ please close this ticket once there are new ones about 1. communicating; 2. actually removing I2P.

#35 Updated by anonym 6 months ago

#36 Updated by anonym 6 months ago

#37 Updated by anonym 6 months ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (anonym)
  • % Done changed from 50 to 100
  • QA Check changed from Info Needed to Pass

intrigeri wrote:

my position that we remove I2P in Tails 2.12.

ACK

IMHO we should announce this ASAP on our blog, or at least on Twitter, which might attract someone to step up to reintroduce I2P into Tails.

If you agree, intrigeri, I think we can just go ahead and do this. In that case I volunteer to do the work.

Yes ⇒ please close this ticket once there are new ones about 1. communicating; 2. actually removing I2P.

Also available in: Atom PDF