Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#599 closed defect (fixed)

Don't try to delete keyfile if a non-persistent client tunnel is deleted

Reported by: killyourtv Owned by: zzz
Priority: minor Milestone: 0.8.13
Component: apps/i2ptunnel Version: 0.8.12
Keywords: Cc: killyourtv@…
Parent Tickets:

Description

Scenario: You have a server tunnel configured that has a destkey file i2ptunnel10-privKeys.dat assigned. You also have a client tunnel with i2ptunnel10-privKeys.dat assigned. The client tunnel will not use this key--it's not configured to be persistent. If the client tunnel is deleted the file i2ptunnel10-privKeys.dat will be renamed to i2ptunnel-deleted-$DESC_OF_CLIENT_TUNNEL-$TIME.

Since the client tunnel was not set to be persistent, there wasn't a key to delete/rename...but the key for the server tunnel was renamed instead. Upon the next I2P restart the server tunnel's dest will be different because a new key (to replace the renamed one) will need to be created.

Thankfully the key was not really deleted, it was only renamed so this could be recovered from (assuming the user realizes what happened).

I think it'd be best if we only renamed/deleted the designated client key if it was also set to be persistent.

Subtickets

Change History (5)

comment:1 Changed 7 years ago by killyourtv

  • Cc killyourtv@… added

comment:2 Changed 7 years ago by kiribati

Can confirm this. It caused the great "oh shit kiri's tahoe introducer moved" incident of 2012. For details see #tahoe-lafs or URI:DIR2-RO:t4fs6cqxaoav3r767ce5t6j3h4:gvjawwbjljythw4bjhgbco4mqn43ywfshdi2iqdxyhqzovrqazua/introducers on the i2p testgrid.

comment:3 Changed 7 years ago by zzz

  • Owner set to zzz
  • Status changed from new to accepted

I can fix the problem as you propose.

The root cause may be, however, that we will pick a privkey file name even if some other tunnel is already using it. The whole automatic file name generation can lead to these and other problems.

Safest thing for now is to always name the server privkey files explicitly when creating the tunnel.

comment:4 Changed 7 years ago by zzz

  • Milestone changed from 0.8.14 to 0.8.13
  • Resolution set to fixed
  • Status changed from accepted to closed

Thanks for the reports.
Fixed in 0.8.12-17-rc as you propose.
There's still some ways to get the privkey files reused or renamed inadvertently but this fixes one of them.

comment:5 Changed 7 years ago by killyourtv

I thought that the proposed method would be an easy way to resolve part of the problem (or at least one of the methods of privkey (re)moving) but I didn't realize it'd be a one-line fix.

Note: See TracTickets for help on using tickets.