Mesh/Software ToDo - Revision history

Tunabananas at 13:08, 25 June 2018

2018-06-25T13:08:20Z

← Older revision		Revision as of 06:08, 25 June 2018
Line 1:		Line 1:
			'''Adding to [[Mesh/ToDos]]!

			- [[User:Tunabananas\|Tunabananas]] ([[User talk:Tunabananas\|talk]]) 06:08, 25 June 2018 (PDT)'''
			----
	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].		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].

Juul: /* Community support forum */

2016-06-20T08:53:55Z

Community support forum

← Older revision		Revision as of 01:53, 20 June 2016
Line 106:		Line 106:

	We should set one up!		We should set one up!

			Maybe [[User:Tunabananas\|tunabananas]] wants to take this on?

			--
			marc/juul

	= Fake captive portal splash =		= Fake captive portal splash =

Juul at 08:43, 20 June 2016

2016-06-20T08:43:00Z

← Older revision		Revision as of 01:43, 20 June 2016
Line 172:		Line 172:

	It would be _really_ useful if someone specifically asks us to help them out. This feature should not allow granting of temporary ssh access to anyone else since that would equate web admin access to root access which we do not want (web admin access should be seen as a relatively low security thing as it doesn't allow you to e.g. install malicious code).		It would be _really_ useful if someone specifically asks us to help them out. This feature should not allow granting of temporary ssh access to anyone else since that would equate web admin access to root access which we do not want (web admin access should be seen as a relatively low security thing as it doesn't allow you to e.g. install malicious code).

			= Firewall rule rewrite and security test =

			See [https://github.com/sudomesh/sudowrt-firmware/issues/96 this issue].

			[[User:Juul\|juul]] will do the rule rewrite and then we'll need someone to test that no traffic is allowed to flow from public to private areas.

	= Nice to have =		= Nice to have =

Juul at 04:59, 17 June 2016

2016-06-17T04:59:34Z

Show changes

Juul: 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..."

2016-06-17T02:52:23Z

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

New page

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)
* ps
* logread
* dmesg
* A dump of all config files (with e.g. wifi passwords censored)