Here is a list of the projects that I'm interested in working on. The is not complete, but these are the ones that I'm more interested in. If you'd like to help, either w/ time, money or encouragement, let me know! Email me at jmg at funkthat.com. Note that some of these projects do have some code behind them. There is no particular order to the projects.
- FreeBSD test lab
A lab where other FreeBSD commiters (at first) can reserve an embedded board, and do testing on it remotely. They will have a jail w/ full access to the network of the board under test, along w/ the ability to power cycle the board. This will hopefully allow more testing of boards.
- FreeBSD embedded autoconf.
A way to do automatic configuration. The idea is when you configure a FreeBSD box, you put a public key, and possibly generate a private key and put them on the fat partition. Then using dhcp or another configuration mechanism, the box asks the network for their configuration, fetch it, and configures themselves to match. The idea is to make devices (like IoT) more replaceable and keeps the configuration in a more centrally controller and backed up location.
- FreeBSD USB thumbdrive.
Using a board that supports USB OTG, using ggate over unix domain sockets over ntunnel, preset a file on a server as a USB umass device. This allows a person to plug it into a game console or other device, and have the storage automatically go to your server which is backed up. Using the above embedded autoconf, security is well maintained.
- PCIe support for ROCKPro64
Add support for PCIe to the ROCKPro64.
- Add host network stack support for bhyve
Use SLIiRP, how Qemu User Networking works so that you don't need to add additional network interfaces.
- File/object metadata.
The ability to tag files w/ data, and share them out. This includes things like tagging people in photos, but also where the file came from. An example of the later is being able to find out what OS release/version of /bin/ls is currently on your system, and where it might be found.
- New file interface architecture.
The POSIX file interface has served us well, but one thing it lacks is integrity. Anyone that does file writing has to add their own logging/journaling logic, or do the poor man's new file/rename in order to do atomic updates. Modern file systems like ZFS and even UFS w/ softupdates, do this for themselves, but currently there is no exposed interface to allow user land programs to make use of these features.
- New ZFS interface layer.
ZFS has a ZPL that mappes the POSIX layer onto ZFS. It'd be nice if there was an interface that exposed the raw ZFS objects to a userland system. This would allow things like a userland program handling it's own lookup layer, and cheaper CAS backed storage.
- Universal Conversion.
An infrastructure to be able to describe conversion from a byte stream to a key/value type structure, and the ability to tie them together. This would generate both a serializer and a deserializer from the same definition.
- encryptthe.net domain
I would like this to be a one stop shop for guides on how to encrypt your traffic and internet. Targetting both users (like installing HTTPS Everywhere), to sysadmins (installing SMTP certificates or HTTPS certs) and more.
- Secure/Privacy DNS Resolver.
This is an attempt to improve the privacy of DNS resolution. The idea is that for domains that support DNSSEC, do the query over tor, and authenticate the responses, this gives the privacy of tor. If a domain doesn't support DNSSEC, provide various options, either, forward to your ISP's resolver, validate through mulpitle tor queries or other options.
- Next gen secure transport.
A new transport that is designed for privacy and security. Basic idea is that machines establish a tunnel, and any connections between the machines are passed through the tunnel. Similar to QUIC, but drop requirement that it's HTTP traffic. Other advantages is that due to cryptography authentication, multipath and moving IP addresses is an easy thing, as the machine can just create a new tunnel, and tell the old machine to transfer/use this new tunnel as well. Best would be to use a new protocol to be siblings to TCP or UDP, but it's unlikely to work w/ modern nat infrastructure (unless it's IPv6), so UDP will likely be used.
- Secure python import: partial complete, see casimport
Currently there isn't a way to ensure that an end user gets the same code that the author tested/wrote against. Or that the code is by the same author as the import. See things like leftpad, or handing off a module to another author that ends up pushing malware into the module. I'd like to see a cryptographically signed way to import python modules and code. This is something like Content addressed Code. The idea is to support something like
from <hash of library or author's key> import module. This will verify the module is signed by the author, or the module exactly matches the hash of the library. This could make it easier to import code from another project. Say they properly put a useful function in it's own file, you could do:
from <hash of py file> import function, and the function would be imported as the database would contain a mapping between the hash of the py file, and where to get it. As the hash would be strongly tied, there'd be no issues w/ injecting malicious code.