This is an integrated TODO list for the FreedomBox project, compiling todos from each of the included projects. Right now, we’re trying to finish 1.0. The 2.0 and 3.0 TODOs are not yet firm.
This file lives in a few repositories:
This section lists each of the projects tracked in this TODO list along with any known repositories for those projects.
Freedom Maker (FM) is the central hub of the FreedomBox project, it builds and installs the file-system image that turns any computer into a FreedomBox.
Bdale Garbee’s master branch is the current root.
The configuration of a FreedomBox is collected in a debian package that can be
installed on any Debian system and configured by running
Petter Reinholdtsen’s master branch is the current root.
Plinth is a web front end for administering every aspect of a Freedom Box.
Nick Daly’s master branch is the current root.
The Debian packaging is maintained on Alioth.
FreedomBuddy manages service discovery between FreedomBoxes, coordinating connections between friendly servers for any service.
Nick Daly’s master branch is the current root.
FreedomBox Privoxy filters out privacy threats and advertising for users while they browse the Internet.
James Vasile’s master branch is the current root.
With SQLite uses an SQLite database as a dictionary in Python.
Nick Daly’s master branch is the current root.
Publish publishes projects (including bug trackers, wikis, and source archives) in the simplest ways possible.
Nick Daly’s master branch is the current root.
Mentions keys that will expire soon.
Nick Daly’s master branch is the current root.
FreedomBox 0.3 [0/3]
Disable Known Passwords
Switch to SSH certificate-only login.
Change plinth to make it possible to create UNIX users using plinth, and upload a ssh certificate to be able to log in as this user. And allow the user sudo access as an option. If we do this, there will be no need for ssh login using passwords. Another option is to use plinth to set the unix password, and not set any passwords by default.
Document Service Ports
- What ports are open?
- What services do those ports support?
- What features do those service/port combinations enable?
# lsof -i|grep LISTEN # netstat -pant
Which interfaces should each of those services be listening on?
Lock Down Service Ports.
Each of those ports should be controlled by the service’s configuration in Plinth.
For example, if a feature is disabled in Plinth, the associated port should be closed whether or not the service closes the port.
The UI might appear like:
- [X] XMPP
- [X] Enable Web Interface
- [ ] Enable In-Band Registration
- [ ] Enable Server-to-Server Communication
When the “Enable Server-to-Server Communication” option is unchecked, the beam ports are closed. When the option is checked, the beam ports are open. If the option is disabled (inactive), the user has customized the firewall or XMPP in ways that Plinth can’t represent.
Each configuration option should be enabled only when Plinth can understand the configuration well enough to interpret and control it.
- State “DONE” from “TODO” [2014-04-28 Mon 21:45]
Cross-Cutting Concern (Hook) Support
- State “DONE” from “TODO” [2014-04-28 Mon 21:45]
Firewall support requires cross-cutting concern support, the ability to add hooks and listeners to allow the system to react to actions, without needing to hardcode all of them.
Use Inheritance Correctly
Subclasses should call super classes’ methods as appropriate:
super(CLASSNAME, self).__init__(*args, **kwargs)
Move freedombox-setup/firstrun.d to Plinth
That way, all the first run config is in one package.
Add “Route all Traffic through Tor” to Plinth Module.
FreedomBox 1.0 [0/3]
A dedicated hacker’s release. All the pieces are there, but not necessarily integrated as well as they should be.
Write Developer Documentation
Take the current state of the FBX and write up how to use all the parts together. Include notes on how to create services. Include notes on who manages each of:
- availability (FBuddy)
- authentication (Apache)
- authorization (OS-level users and groups)
Add Single Sign On Support
Each service should use the FreedomBox’s own user-level logins and should not manage its own user names or passwords. The goal is to improve security by saving users from having to juggle multiple passwords.
If each service for each user on the FreedomBox manages its own users and passwords, then each service will have completely unrelated usernames and passwords for each user. To avoid password hell, the box should manage accounts and passwords for each service: each service should let the box manage logins.
We can do this via the REMOTE_USER request header: Apache can handle this header through LDAP with mod_authnz_ldap and PAM with mod-auth-external (packaged as libapache2-mod-authnz-external), while nginx can handle this header through PAM with ngx_http_auth_pam_module (packaged in Debian) and LDAP with nginx-auth-ldap (not packaged in Debian).
The authorization process should be based on user groups (“Require Group Wiki”). It’s up to the individual service to decide what it wants to make available to the user: either a shared resource (wiki) or a single service per user (FBuddy).
Now, each service just needs to support the REMOTE_USER header. Adopting this method should make it easier to transition to using PGP keys as authenticators later: the LDAP system should be able to associate system-level accounts with PGP keys.
Determine Where Smooth Upgrade Paths Exist
Smooth upgrade paths will not exist before 1.0, there’s simply too much that could change at any time. We don’t want to constrain ourselves to bad architecture decisions that don’t scale. However, at some point between 1.0 and 3.0, they must exist. So, will smooth upgrade paths exist from 1.0 to 2.0 and beyond, from 2.0 to 3.0 and beyond, or only from 3.0 and beyond?
Release 1 End User Service
At least one service should work with Plinth and use the SSO system, like the wiki project.
Make Plinth Recognize Module Manager’s Changes
Automatically Set Time on First Boot
Prompt user to verify time after detecting it from one of these methods:
- [ ] Detect time when opening IP connection from server.
- [ ] Detect time by sniffing wifi beacons.
- [ ] Detect time by sniffing bluetooth beacons.
- [ ] Detect time by sniffing IP packets and DHCLIENT REQ and ACKs.
FreedomBox 2.0 [0/11]
Generally Useful, includes service configuration and UI polish.
Infrastructure packages should be available in Debian Testing.
Clarify Authentication vs Authorization in the System
Clean up FBF Wiki
Coordinate End User Documentation
Update FBF.org Style for Butterfly Logo
Freedom Maker [0/1]
Use Official Debian Archives Only
FreedomBox Setup [0/2]
Deliver FreedomBox Setup Debian Package
Make sure the First Boot Process Meets Design Docs
- User plugs ethernet cord into computer and DreamPlug’s inside ethernet port.
- User plugs in and boots DreamPlug.
- First boot process completes, DreamPlug restarts.
- User logs into Plinth and configures admin accounts, certificates, and networking (if necessary). Requires dhcp-server.
- User replugs ethernet cord into DreamPlug and router.
- User uses FreedomBox normally.
Depends on Teach Plinth to Manage Networking.
Include in FreedomBox Image
Write FreedomBuddy Threat Model
Add Contracts to Functions.
Use PyContract to verify functional contracts.
Finish Introduction System
- Sender exports public key to file.
- Sender exports signed location message to file.
- Sender archives both files.
- Sender and receiver exchange the archive.
- Receiver unpacks the archive.
- Receiver imports public key.
- Receiver verifies and imports signed location message.
Add Default Services [0/3]
Make a default set of services available to make it easy for folks to start hosting services for someone else. It could be a sort of “add a new user” wizard that sets the default services and creates the introduction message archive.
We need to create a “default” key that is loaded into the shelf only when the shelf doesn’t already contain a default service set. That service set should contain the current default services:
- http listener
- http sender
- http monitor
- cli monitor
Load Default Services
If default services aren’t found in the saved data, they’re read from the config file.
Reject “Default” Key Updates
The “Default” key is a special, protected, key (maybe 0, maybe “default”) for which all external service updates are rejected, in the same way the “-update-time” service suffix is protected.
Copy Default Services when Adding a New Key
The services you want to host for other people are copied to their service list whenever a new key is added.
Finish FreedomBuddy UI
Support friendly names for servers and services. I expect Plinth will scrape this data from FBuddy to display in an internal Plinth module.
What would that UI look like?
|The Lead Rose (emoblog)|
Here, Joe provides both a blog and an emoblog.
If the service specifies a friendly name:
Service Name (service type)
Users must specify a friendly name for Servers.
Deliver FreedomBuddy Debian Package
Split Message Parsing per Encryption Method
This will allow FBuddy to handle multiple encryption schemes.
Split Database Saving/Loading Code into Separate Module
Move the db code into /src/db/(modulename).py.
This’ll allow us to support multiple database backends that we can preferentially check for data. LDAP first, shelf second, etc.
Add LDAP database backend
Add REMOTE_USER Authentication [0/4]
- [ ] Put FreedomBuddy behind Apache.
- [ ] Apache config requires users in freedombuddy service group.
- [ ] HTTPS controller rejects HTTP connections.
- [ ] HTTPS controller requires REMOTE_USER.
Convert to Isis’s python-gnupg
I don’t trust Vinay’s python-gnupg, because it took him forever to fix
Popen(shell=True), and only two years to actually provide a source repository
(from v0.3.6 and up). It also looks like Isis’s python-gnupg has diverged
widely from Vinay’s. We need to unify these at some point. Sigh.
Include DHCP Server
Use NoLogin Shell for User Accounts
For this to be successful, users must be able to manage the system without loggging into the system. If we must log into the system to manage it while building it, it’s not release-ready.
Remove or Disable “root” Account.
Remove or Disable “fbx” Account.
Use FreedomBuddy and/or Tinc to connect all services.
Services may have to become FreedomBuddy aware. Right now, it’s impossible to say “connect to Joe” and have that command mean anything useful.
Glue Pieces Together
Deliver FreedomBox Debian Meta-Package
Include a Smarter MAC Changer
Rely on something like this:
Make sure it’s packaged, though.
Teach Apache to use PGP keys for Client Authentication
Teach FireFox to use PGP keys for Server Authentication
Maybe we can fake this by teaching Firefox to handle PGP-certified-X509-certs?
Make SD Card Images Resize Themselves on First Boot
If the primary partition is the only partition on the SD card, and it doesn’t take up the entire SD card, resize the image to take up the entire SD card on the first boot.
All Services Notify Listeners on Enable/Disable
So far, only the Owncloud service does this.
Enable Automatic Daily Package Updates
Update Cron Job Schedule Based on System Load
Record system load, change scheduled job timing based on average system load.
Suppport local server connections.
Can clients on the local server exchange messages?
Suppport server connections.
Can cilents on the local server exchange messages with remote clients?
Key Report [0/3]
Automatically Message Critical and Warning Key Owners
Package Key Report
- State “WAIT” from “TODO” [2014-01-29 Wed 20:33]
Jonas submitted bug 722554.
Make Human-Readable Mode
The output is intended for other utilities and isn’t human readable right now. There should be such a human-friendly mode.
Support more services as Plinth modules. Make sure they:
- Work only over HTTPS,
- Defer authorization to Apache’s REMOTE_USERs.
Run as non-root user.
Probably shouldn’t even run as
www-data, but as
plinth user, to
compartmentalize permissions as much as possible.
Reorganize Plinth’s Module Structure
To reduce technical debt, we need to reorganize plinth’s modules into something more organized. The available directory has the current “installed/” structure, while the enabled directory replaces the root of the modules directory.
It probably looks something like:
modules/available/ modules/available/lib/auth.py modules/available/owncloud/owncloud.py modules/enabled/ modules/enabled/auth.py modules/enabled/owncloud.py
It may be useful to keep enabled in a flat structure (allowing you to swap auth methods in and out, for example), but maybe it’d be easier if the modules kept the nested structure.
Have dependency based modules
Currently there is an numeric order in which each module is loaded. This provided by the module itself. This can quickly get out of hand for large number of modules, especially if there are developed outside the main repository by other developers. Create a system in which module load order is calculated based on module inter-dependencies.
Furthermore, many of the currenct dependencies are actually fake. Module providing URL /x/y/z has to be dependent on module provding URL /x/y simply because of limitation of the current rudimentary path router. Any modern web framework does not have this limitation (see for example, bottle, Django). We should use one of those frameworks for routing to remove most of the dependencies.
Use a web framework
There are many pieces in Plinth that are re-inventing the wheel of web frameworks. Most of these pieces are rudimentary and have problems that have been solved repeatedly elsewhere. This includes path router, forms, simple variable storage, MVC, authentication framework, etc. Choosing and using a good web framework will lead to fewer bugs, greater flexibility, higher quality and more readily available documentation.
There are many such frameworks for Python and many of them allow choosing small components while leaving out the rest. This should ease transition.
To make Plinth an attractive target for more developers to contribute to, it needs to have clean and readable code and framework. The following are the areas of improvement.
Add a HACKING file
Add a HACKING file that explains how to install from git or tarball, how start hacking code, debug techniques and any other tips. A developer familiar with Python should be able to setup in under 10 minutes and start cooking patches. Install and test process should be fun for enthusiats brave enough to test git code.
Follow coding standards
Not just any coding standards but the Python coding standards. This include pep8 and the official Python style guide.
Setup a code checking tools
Use and write documentation on Emacs/Vim integration of pylint, pep8 and pyflakes. Also setup a simple shell script to run these tools on command line.
Have license headers
Although license of each file is clear, it is conventional to have a license header in each file. This should ideally also contain the copyright year and list of authors.
Have better logging framework
The current logging wrapper cripples many of the awesome functionalities provided by Python logging module. Python logging is quite nice. Most modules play nice with it (including CherryPy). Improve logging so that we retain the Python logging module niceties and make every other library we use play into it.
Get rid of global code
Importing a module should not have side-effects. Currently there is a lot of global code that runs in many modules that is problematic. Organize the global code into methods and call them explictly. This is almost a necessity for writing good test suite.
Simplify setup process
The current ‘make install’ setup does not seem to do enough to actually make Plinth work. This is because of the way various paths are being read from configuration or as hard-coded (example ‘actions’) path. Simplify installation and make Plinth work immediately after ‘make install’. Also simplify path configuration. This should also lead to less effort in Debian packaging.
Most Python programs (including daemons) have a much simple way of installing. Most of the time it is based on setup.py. Setup.py gives us some nice features such as the ‘develop’ command etc. Write setup.py instead of doing most of the work in Makefile.
Write a module developer guide
Information on how forms, menus, plugin loading etc. work is rather limited. If we are to see an explosion in the number of modules available for Plinth we need to write a module developer guide explaining, with tutorials, how to create new modules.
Many modules have quite a bit of html code in them. Improve the situation by moving the code to theming/templating system.
The following items should help:
Ability to run Plinth as non-daemon mode
Ability to Backdoor/Manhole into Plinth
Some documentation on using pdb
Remove use of exec()
- State “DONE” from “TODO” [2014-04-29 Tue 21:14]
Python exec() is being used in many places where it not all that required. Apart from resulting in less readable code, it could prove dangerous. All the places it is being used, it can be replaced with the use of getattr(), locals() etc.
Move Plinth’s source to
The top-level directory should be reserved for project structure, not project code.
Teach Plinth to Manage Networking
includeSubDomains to HSTS Header
This will require lots of debugging and patching for each additional project we host.
Plinth Handles Missing Actions Gracefully
If an action isn’t available, Plinth should handle that failure gracefully and not crash or ignore the missing action.
Make (OwnCloud) Setup Page Smarter and Asynchronous
OwnCloud setup (and any step that could potentially take a long time) should be better handled within Plinth. Right now, we don’t handle it at all and just fork a process in the background, leaving the user to wonder why the service isn’t available, even though the system has obviously refreshed the page.
We don’t, but should, land the user on a page that polls the state of the install every few seconds with a several-minute countdown timer. When the timer reaches zero, the page redirects the user to an error page. However, if the setup process finishes at any time before then, the user is redirected to the OwnCloud install.
Ikiwiki can use the http_auth module to manage logins via REMOTE_USER and can take the setup logic from Plug Server’s Wiki Setup Scripts.
Basic module that can setup pagekite now exists. Limitations are that only HTTP and SSH services are supported. It only supports pagekite.net account. Explore using other FreedomBoxes as frontend servers. Consider migrating the pagekite action script to use augeas (or so) instead of directly modifying the configuration files.
Create Generic Service Frameworks
For example, provide a “vpn” command to client services that specifically need it so that we can swap out VPN backends at whim. This would also be handy for defining functional dependencies between modules, for when one module needs to enable a feature in another module to function correctly.
Add MAC Changer to Plinth
Bounce any/all active interfaces to come up with new MAC addresses.
Use Publish to publish Plinth’s Source
That’d be useful and convenient, but should exclude the data directory.
Start Community Heartbeat Support
Boxes should be able to ping other boxes for health information about their mutual connections and other data. Boxes could run tests on other boxes to make sure they’re still in one piece and send out communal alerts when a box is found to be failing (“Alice has a bad network connection,” “Bob’s sending out malware!”).
Perhaps start with distributing
/etc backups, key(ring) backups, or time
Might be broken out into a separate heartbeat project.
Integrate Tinc into Plinth [0/1]
Divide plinth/modules into modules/available and modules/enabled
Making it look a little more like the Apache configuration will make it easier to manage and understand in the future.
/etc Configuration Manager Module
Allows user to roll back and fork their
/etc configuration via etckeeper.
How should Plinth refresh its configuration? On each page load? Should it cache each settings file’s values based on the last modified date (akin to make)?
etc-keeper --commit Around Each Action
/etc. To make
/etc manageable, we should commit
changes before and after running each action.
Committing changes before each action will capture the system’s state before the action changes things. This can include changes made outside Plinth.
Committing changes after each action will capture the system’s state after the action changes things. This should only include changes made by Plinth.
Combining both before and after snapshots should allow users to separate changes made by Plinth from changes made through other methods.
Just automatically commit changes weekly so we can track them over time, to prevent them from becoming unmanageable.
Add Service Delivery (Connector) UI Support
Users should be able to configure the system they want to serve a service over (PageKite, Tor, Public IP, etc.).
design Directory Support
Make sure it works in Debian Testing.
Release Debian Package
Add a Deploy Action
This action copies Publish to a subdirectory of the current directory and adds a
startup action to
VPN Support [0/2]
When available, FreedomBoxes will construct VPNs to communicate between one another. It seems unlikely that all these VPNs will form a single, large, network but, rather, that each FreedomBox will construct its own VPN network by which it can reach all of its trusted peers. This should help to prevent non-mutually trusted peers from seeing one another and leaking the social/network graph.
When VPNs aren’t available, FreedomBuddy can still be used to create direct connections over arbitrary networks. However, this is less desirable as it doesn’t abstract away the network protocol and reqiures each application to be able to use the protocol. For example, if your browser doesn’t understand how to handle the webserver at gnunet://00000000, you’re out of luck. There is still the option of just communicating directly over FreedomBuddy, but that’s a really roundabout way of doing things.
We should include a VPN system. OpenSwan, Tinc, and librevpn appear to be options.
James recommended OpenSwan over the similar StrongSwan.
Include Tinc [1/2]
Actually Include Tinc.
Validate Tinc’s Suitability [4/4]
- State “DONE” from “TODO” [2014-01-29 Wed 21:13]
According to Guus on the “[Freedombox-discuss] [James Vasile] tinc rollout and fbox” thread, the answers are as follow:
- [X] Can Tinc work, now?
- [X] Can Tinc work, ever?
- [X] Unpatched Tinc Problems
- [X] Patched Tinc Problems
[2013-08-13 Tue] Nick Daly
Yes, Tinc has problems, but they seem to be resolvable or ignorable:
As for those security points, we could address them and ship our own Tinc that is incompatible with existing Tinc. Going off of the problems listed at http://www.tinc-vpn.org/security/ I see a relatively easy fixes.
- Randomize the IV for each packet.
- Increase default HMAC length or just config it to be longer.
- We could add padding in RSA. And there are easily-implemented techniques for defending against RSA timing attacks.
- The Auth Protocol problem doesn’t look worth fixing to me. In paractice that’s a DOS attack unless I’m missing something.
The cost of these is dev time and a little on the performance side.
But we can ship Tinc as-is and fix those points over time. Tinc is rather good security for now.
[2014-01-29 Wed] Nick Daly
I just remembered that someone mentioned these issues were fixed in a 1.something Tinc release… Where in Pete’s name on the mailing list was that?
FreedomBox 3.0 [0/2]
A generally usable consumer device.
Viable upgrade paths must exist between 2.0 and 3.0.
Generally Disable Logging
FreedomBoxes shouldn’t be able to compromise previous end users after the box is affected by malware.
Offline-Long-Term Key Support
The box user’s long term keys shouldn’t exist on the box.
Split Plinth into Multiple Debian Packages
Every (non-core) module should be its own package to make remixing the system easier (i.e., create a Plinth-Owncloud module that contains modules/owncloud.py, which depends on Owncloud).
Survey User for Concerns, Enable/Disable Options Appropriately
Is the user concerned about:
- End user location anonymity?
- End user identity anonymity?
- Server location anonymity?
- Server identity anonymity?
Change default options based on user’s answers. If we can’t support a class of user, let them know. Might we also be able to use the geolocation to guess at a good set of defaults?
These todo items aren’t currently scheduled for any milestone.
The system as a whole would be easiest to manage if we were able to provide recommended client-device applications as well, though nothing more than a web-browser with identity management should be necessary.
Automatic Performance Benchmarking and ETA Estimation
We can manually test CPU and disk performance (number of digits of pi calculated in 5 seconds, number of incremental file reads and writes in 5 seconds, respectively) and use that as a benchmark to provide reasonable estimated-completion times for specific tasks:
- Benchmark any computer on the standard test actions.
- Benchmark the time a particular action takes to complete.
- Benchmark the target system on the standard test actions.
- Estimate a particular action’s completion time by scaling the time benchmarks appropriately.
If the benchmarks are quick enough, we can even re-benchmark every time the FBX or Plinth start up.
Look into upstreaming @synchronized
The Orange Duck provided a beautiful @synchronized implementation, which should be upstreamed into a PEP so it’s available everywhere. Then, Plinth (and other projects) should use it for their synchronized sections.
Freedom Maker [0/1]
Make Freedom Maker Smarter
Do a better job of abstracting away devices into configuration options. For example, if we’re building for a DreamPlug target, we should enable the blink-blinkenlights option (the DreamPlug has LEDs we can use to signal to the user), but that should be disabled for a RaspberryPi, as that functionality isn’t available at best (and might cause undefined behavior in the Pi at worst).
Break out devices by type:
- DreamPlug v1
- VirtualBox Image
These capabilities can go into FreedomBox Setup if they can be detected dynamically.
Teach Plinth to Manage a Mail Server?
Difficult: necessary MX records aren’t decentralized or zero-configuration friendly.
A few instructions:
These items need to be thought about more.
Think about trust ratings
Services can announce how much faith they have in each peer for any particular purpose. That’d be neat.
For example, if a service starts receiving updates from a peer that have future time-stamps, it should signal that the peer has a screwy clock.