Opened 7 years ago

Closed 3 years ago

#6824 closed task (wontfix)

Torrouter Update Mechanism

Reported by: proper Owned by: ioerror
Priority: Medium Milestone:
Component: Archived/Torouter Version:
Severity: Normal Keywords:
Cc: ficus@…, adrelanos@… Actual Points:
Parent ID: #20747 Points:
Reviewer: Sponsor:

Description

How do you suppose Torrouter gets updated? Do you intent to use the Debian repositories?

Debian packages will require updating. At some point even a distro upgrade will be required. Also Tor has to be updated.

Torrouter is supposed to be run by normal people who don't like or can't administrate the box.

One buggy update in Debian may result in a lot boxes no longer booting, no longer connecting or no longer being accessible over the web interface.

Perhaps it would be best if tpo would handle all updates? You could have a stable distribution and a testing distribution with the goal that never too many boxes break at once and that they never need manual administration.

Child Tickets

Change History (6)

comment:1 Changed 7 years ago by ficus

Cc: ficus@… added

What is tpo?

I think following debian security updates plus having buttons in the web interface to do full system upgrades (or dist-upgrades) is a good place to start. Users should definitely be able to opt-out of any automatic updates at all. I'm wary of engineering or over-thinking a complex solution to this concern at this point. Delaying automatic updates to once a week (random day of week) might be a good balance between timeliness of updates and robustness against sudden failure (assuming it takes ~24 hours to catch a problem with changes).

An update-from-usb-stick-at-boot mechanism is a good recovery mechanism, but requires a non-reset button that could be held during boot (or perhaps just a more sophisticated bootloader).

Some router distributions (pfSense) use a frame-buffer-like update mechanism so changes can be reverted to last-known-good in case there are problems after an update.

Should all updates be fetched through Tor? What if Tor is unavailable because updates are required to connect to the network? I guess deciding that would require threat modeling.

comment:2 in reply to:  1 Changed 7 years ago by proper

Cc: adrelanos@… added

Replying to ficus:

What is tpo?

torproject.org

comment:3 Changed 7 years ago by ficus

Some background and references:

"Safe upgrade of embedded systems" FOSDEM talk (2012)
https://archive.fosdem.org/2012/schedule/event/699/130_Presentation_Safe-Upgrade.pdf
Describes a bunch of strategies. Notes problems with using package-based upgrades.

NanoBSD update process (manual). Have two rootfs partitions plus an extra configuration partition. Upgrade by writing to the "other" patition, then try to reboot into it; if there are problems fall back manually to the first partition to fix the issue.
http://www.freebsd.org/doc/en/articles/nanobsd/howto.html#AEN218

pfSense automates the above through the web interface:
http://doc.pfsense.org/index.php/Can_I_upgrade_my_pfSense_through_the_web_interface%3F

comment:4 Changed 7 years ago by ficus

My current thinking is that the build and release process for torouter should
be to have regular versioned updates of the entire image (configuration
defaults, kernel, most of userspace) combined with fully automated apt security
updates for critical network daemons (tor itself, ssh, ntp, dhcp, any http
daemon) pushed by torproject.org, possibly tunneled through the tor network
itself. users should be notified of available image updates through banners in
the web interface and/or an announce email list.

Maintaining stable security-fix branches of the tor daemon for every release of
torouter would probably be too much work, so every revision of torouter would
pull from a single apt repository (either the vanilla torproject repository or
a special torouter repository which would track "most-recent-torouter's-tor
plus security updates"). this would mean that all torouters would be running
the same recent tor daemon debian package unless automatic updates had been
disabled. a new point release of the torouter image would mean an automatic
update of the tor daemon on all active torouter devices, even if those updates
included feature additions or changes of behavior.

One problem could be reconciling additions and modifications to the vanilla
torrc with the torouter-default or user-modified torrc; perhaps some mechanism
like a torouter-torrc.deb package could override the vanilla torrc? another
would be larger changes to the tor daemon which would break functionality for
old point releases of torouter; i'm not sure what tor's backwards compatibility
policy is or how frequently this scenario would occur.

comment:5 in reply to:  4 Changed 7 years ago by proper

Replying to ficus:

users should be notified of available image updates through banners in
the web interface and/or an announce email list.

Ok, Bob buys a Torrouter and plugs it in. Then continues with life. Why will remembered looking into the webinterface? E-mail could work better.

The Tor developers will certainly have some experience with Tor relays and bridges. How reachable are the admins? How communicative are the admins? How up to date are their Tor versions? How do they (automatically) upgrade?

That experience would very valuable here.

comment:6 Changed 3 years ago by irl

Parent ID: #20747
Resolution: wontfix
Severity: Normal
Status: newclosed

A revival of this project would probably have a different enough architecture that this discussion would have to happen again. Closing as no longer relevant. See also #20747.

Note: See TracTickets for help on using tickets.