Tails

#1 Updated by anonym 2016-05-11 03:35:13

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 2016-05-11 05:56:56

> 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?

#6 Updated by intrigeri 2016-06-02 12:58:14

> 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 2016-06-02 20:45:32

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 2016-06-03 10:34:49

> * 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 :/

#11 Updated by intrigeri 2016-08-01 03:41:18

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.

#14 Updated by intrigeri 2016-10-01 21:00:23

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 Feature #8183. Fingers crossed.

#15 Updated by intrigeri 2016-11-02 10:50:57

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

#17 Updated by intrigeri 2016-11-02 10:55:27

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 Bug #8280 and Bug #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 2016-11-04 11:28:11

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

#19 Updated by anonym 2016-11-04 16:15:07

intrigeri wrote:
> Data point: Feature #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 2016-11-05 19:20:21

> 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 2016-11-06 18:10:14

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 2016-11-07 10:38:07

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 2016-11-07 10:46:07

> 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.

#25 Updated by intrigeri 2016-12-04 17:26:26

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.

#27 Updated by anonym 2016-12-28 15:53:58

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 2016-12-28 16:13:26

>> 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 2016-12-29 16:41:42

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

• We’ll follow intrigeri’s proposed deadlines in Bug #11276#note-25.

• 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. Bug #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.