Jump to navigation
Jump to search
Newer edit →
Revision as of 19:52, 16 June 2016
2,988 bytes added
19:52, 16 June 2016
Created page with " The purpose of this page is to provide an overview over features we want for the next milestones. We also track feature requests and bugs on [https://github.com/sudomesh/sudo..."
The purpose of this page is to provide an overview over features we want for the next milestones. We also track feature requests and bugs on [https://github.com/sudomesh/sudowrt-firmware/issues the github issue tracker].
This page is an attempt to list the software ToDo items that we are aiming to complete before a wider beta launch.
= Web UI =
== Dashboard ==
== Extender node UI ==
= Fake captive portal splash =
We need a better splash page! Also we need to ensure the captive portal is working on the new exit server.
= Removing our root access =
Having root access mesh nodes means that we can potentially listen in on traffic on the _private_ router used by the node operator. That is: The router they use for their internet connection. This can be done by spoofing MAC addresses or using ARP flooding. That's bad. We don't want this power. How do we get rid of it.
We only need root access to nodes for three reasons:
* To upgrade the firmware
* Remote password reset for people who forgot their password
* Diagnostics / debugging
Upgrading the firmware of course means that we could give ourselves root access or include whatever malicious code in the upgrade. In the end users will have to trust our firmware and upgrades, so why even bother taking away our root access?
First, if upgrades are sent out as signed packages then those are easy to inspect and verify. Most node owners won't do this but at least we can make it an option for users to check the upgrades before installing them and even if one node owner checks them then they could find any potentially malicious code and alert everyone on the mesh to the problem.
Second, there is a big difference between "we will sometimes send you a firmware upgrade, but you if you want you can check the contents before you install it" and "we can log into your device at any time and look at your private traffic and there is no way for you to know if we've done so, but we promise we won't do this".
== Firmware upgrade ==
We should distribute signed .ipk packages and sometimes sysupgrade images. The clients will download them (to begin with from a central repository), verify and either install or wait for the user to authorize the install.
== Remote password reset ==
We have a web app on a server. The web app asks security questions or verifies via sms and emails the node operator a password reset code that they copy and paste into a field on the node's web UI. This password reset code is actually a signed and encrypted JSON message saying "allow one password reset". The user then pastes this code into the Web UI and enters a new password. The password reset key should expire fairly quickly if unused.
== Diagnostic / debugging ==
We want access to:
* babeld -i
* notdhcpserver -i
* ip addr show
* ip route show
* ip route show table public
* iw list
* iw dev
* iwinfo <dev> <cmd> (yes all of them)
* A dump of all config files (with e.g. wifi passwords censored)
Retrieved from "
Oakland, CA 94609