roadmap for a binary release and announcement

[hannesm]

• documentation of the different unikernels embedded in this repository
• udp #1
• server #2 (not needed for a release)
• more testing in different scenarios, especially in respect to authentication mechanisms (client certificates et al) #42 #43 #44 #45
• we authenticate the remote with CA (but no CRL :/), and there’s as well “verify-hash” for fingerprint auth, which we should support #34 #35
• revive app/openvpn_client_lwt.exe #7
• support Remote_random by randomizing remotes once at startup (done in #69)
• qubes integration (similar to qubes-mirage-firewall being able to act as netvm (IIUC) and dynamically get more client VMs whose traffic is routed (and encrypted) over the tunnel)

(please (esp @cfcs) extend by commenting on this issue or editing this task list if there's anything missing from the above list)

[cfcs]

• documentation of supported subset of configuration options
• configuration file: (passing in at boot)
  • qubes: reading config file from QubesDB
    • qubesdb keys are capped at 3k bytes, xenstoredb at 4k: https://github.com/QubesOS/qubes-core-qubesdb/blob/master/include/qubesdb.h#L93
    • QRexec service that provides the configuration file from dom0 could be a viable, easy way
    • read-only block device using qvm-block a -p could work, but since it needs to be a block device that only works for storage backends that are backed by block devices (ie not file), and we have to pad to block size (512) - not nice
  • solo5: blob idea?
    • write up proposal for solution
      • max number of blob keys
      • max size of keys, individual / cumulative ( < 1 MB?)
      • how to access from OCaml
      • how to unify with other targets (qubes/unix), can be done from the OCaml side just plugging in reading from a file / qrexec service
        • failure semantics should be identical (fail on boot rather than on access, ...)
        • qubes: configure target VM for the qrexec service in qubesdb
      • qubes: in general, can we do something to support manifest-style configuration? ie provide petnames for devices from dom0?
        • external packages on Qubes can define new VM types (with a template for volume_config - https://github.com/QubesOS/qubes-core-admin/blob/master/qubes/vm/dispvm.py#L55-L83 - by overriding the frontend-devoption we can hardcode the xen block dev id assigned to the volume; this gives us a mapping from petname to block dev id that we can load in the unikernel). This could be a way forward, with tooling to generate unikernel (aka qubes kernel) + vm type (block dev template etc) as an installable rpm. In practice though we can likely make do with the persistent rw and the non-persistent rw (swap) and using QRexec for the configs for most applications. We need to update mirage-kv-xen(or whatever that is called) to allow pointing to specific block ids for these two types of storage. Manifest could point to additional ids (xen id = 202 * 2**8 + minor id, with minor id 0 starting at xvda, xvdb being 1, etc).
• tuntap improvements PR mirage/ocaml-tuntap#34
• set routes on lwt + unix target

[xbc5]

I'm wondering what the status is for Qubes support?

[hannesm]

there has been no further work on QubesOS support. from the packaging site, there is https://builds.robur.coop/job/openvpn-router/ that relies on caravan as a post-link step to integrate the configuration into the image. (NB: This is a hvt image, but something similar could be done for a QubesOS openvpn client).

[hannesm]

I'm closing this laundry list of things. The major parts have been achieved, the issue tracker here contains other things. We should instead use a milestone and annotate the specific issues.

The remaining idea from here that I have not (yet) copied is the solo5 blob idea. The reason is that (a) it is not well specified (b) we can use the QubesDB on QubesOS, and a block device on solo5 (and/or boot parameters). If there are pressing issues, don't hesitate to open a fresh issue with one topic.