Maybe debian / raspian support is a good idea.

Swap to the most recent version of Tor, rather than the stable version. Again, unless this is in AUR, I will keep it low priority.

not very useful, but...

set macchange to run at init and change the MAC of all the interfaces on the system.

The current network configuration for Arch Linux is functional, but archaic (ha! thats what you get for following bleeding edge distros). It should be netctl based now.

See title.

Need to check that the iptables script (and other settings) are consistent with the recommendations outlined here:

https://lists.torproject.org/pipermail/tor-talk/2012-October/026226.html

replace NTP w/ tlsdate

https://github.com/ioerror/tlsdate

Not sure what this buys us, so I'm gonna call it low priority. Unless there is already an AUR package for it in ArchLinuxARM ...

Not a bad idea to have a management tool or configuration tool to help setup the initial internet access and such.

• ask user for the country they live in to optionally only use entry nodes in that country, to avoid data packets getting routed over country borders. This could reduce the probability of traffic correlation by NSA/GCHQ for some users.

Not sure how to do this, so, low priority. :)

https://tails.boum.org/blueprint/more_efficient_memory_wipe/

steal something from either TAILS (above) or Liberte Linux, to wipe the memory on shutdown... this is, again, not a high priority. There are no public tools for dumping RaspberryPi RAM from a cold boot (trivial to solve), but more importantly there isn't much need for this.

I have found that relying on a single tor DNSPort for all DNS queries (1) sometimes fails (presumably when the circuit is renegotiating) and (2) can be a big bottleneck when doing lots of lookups.

I got much better performance/reliability by using dnsmasq to answer queries and proxying the requests out to several tor DNSPorts bound to localhost as upstream DNS servers, like so:

/etc/tor/torrc

DNSPort 127.0.0.2:53
DNSPort 127.0.0.3:53
DNSPort 127.0.0.4:53

/etc/dnsmasq.conf

no-hosts
no-poll
no-resolv
listen-address=127.0.0.1
port=53
bind-interfaces
server=127.0.0.2
server=127.0.0.3
server=127.0.0.4

Aside from just having more bandwidth/load balancing/failover that you naturally get from having more than 1 place to send data, I suspect that dnsmasq responds more efficiently than using iptables redirection.

I guess the thing I'm not sure about is if doing this meaningfully increases attack surface or not? I get that it is exposing code to the network that doesn't have to be exposed, which is definitionally increasing attack surface and which generally doesn't ever make things more secure.

However, dnsmasq provides a lot more fine grained control over how/if DNS requests are answered, which would potentially be a more helpful mitigation if the console is compromised than having iptables pass everything on port 53 to tor's DNSPort, which may or may not handle unexpected input as elegantly as dnsmasq does. Also, this removes iptables from anything DNS related, so there's that too.

Automapping to .onions also works fine using this method.

Thoughts?

The current default systemd can handle setting up your local network, serve local DHCP client IPs, and do DNS by just configuring /etc/systemd/network/eth0.network file:
[Match]
Name=eth0
[Network]
Address=172.16.0.1/16
DHCPServer=yes
[DHCPServer]
DNS=172.16.0.1
EmitDNS=yes

Then you can install iptables and tor with the same configs and it works. You can write an eth1.network file to handle the public connection similarly.

All you need to install is tor and iptables with the same configs. It makes things a lot simpler and I'm happy to submit a pull request, but I don't know if trusting systemd with that much of the networking stuff is the best idea as people have strong feelings about it.

https://github.com/jacook/logrunner

add support for logrunner, replace the logrotate stuff which is likely to kill an SD... also, storing logs in a RAM disk is definitely better security.

Arch no longer offers img files for sd cards to setup the OS, they advise using fdisk to make a boot & root partition the dding the contents of the latest build fetched from them as a tarball.

I can add a script to do this and update the readme if you think that would be helpful.

VirtualAddrNetwork 10.192.0.0/10             
AutomapHostsOnResolve 1                                              
TransPort 9040                                                          
TransListenAddress 172.16.0.1

replace with:

VirtualAddrNetworkIPv4 172.17.0.0/16