The MirageOS Documentation

Agenda

• Security advisory process
• TLS status
• Quality and Test
• Mirage.io status
• 3.0 Planning

Attendees: Amir Chaudhry (chair), Thomas Gazagnaire, Matthew Gray, Sean Grove, David Kaloper, Thomas Leonard, Hannes Mehnert, Nicolas Ojeda Bar, Mindy Preston and Magnus Skjegstad

Notes

Security advisory process

Hannes brought up that at the moment, the project doesn't have a method for dealing with security advisories or incoming reports of security issues. We should set up some form of advisory system. This would likely include a website that lists known security vulnerabilities and might also include a mailing list for people to report critical issues. This would be more general than just for TLS and should cover anything MirageOS-related.

Amir mentioned that Xen Project already has such a process so it's worth looking at that and seeing what we can adopt from it, rather than having to invent everything from scratch. In order to keep this moving, Amir suggested that Hannes submit a page to the site as an RFC on the procedure we should follow.

TLS status

Still thinking about entropy in the security stack. We're currently using the internal APIs of nocrypto, which is not ideal and we'd like to adjust this to have a better abstraction. The original idea was that the RNG would extract ambient entropy and use that for crypto purposes but it seems but it seems that no-one else really needs/uses entropy. It appears that for most other users, a pseudo-random stream is sufficient for their purposes.

We need to think about this carefully and it will involve more in-person discussion. It's a hairball as things are not necessarily in the right places currently) and there's the risk of confusion as people add their own entropy sources for specific purposes — poor changes propagate through people's code bases. It's not just consumers of entropy but also providers of entropy that need to be addressed. This leads to several structural issues and we need to figure out what to do. An open question is how many people expect to write code that needs an entropy interface.

Getting the entropy story figured out will likely delay the next point-release of Mirage (2.4.0) — if it isn't fixed. DavidK will send an email to the mailing list to continue this discussion. [Edit: The thread is "Update on entropy".]

Quality and test

There's work towards a virtual network interface, which can run TCP and iperf tests at the moment. The goal is to be able to test the network stack but without needing an actual network (test between unikernels). At the moment, it's just been tested with two unikernels and we've reported issues with Lwt. If (and only if) you add a delay on write, then it works ok (this was discussed on the mailing list). Will stick with two unikernels for now and later on, we can add support for more. Also done some work on netfront and pcap and used them to do some simple tests for now. In time, we should be able to write some meaningful tests

At the moment, not many people have had a chance to look at coveralls and bisect on Dave's repos — Mindy's had a look but ThomasG hasn't yet.

Mirage.io status

Last status was that the second Bytemark machine was being reinstalled to run a version of Xenserver (with xapi). The idea is that this would then host the Mirage website. We need Anil present to discuss this so this item is moved to the next call.

3.0 Planning

Following on from the previous discussion a month ago, it's becoming clear that there's an emphasis on improving quality of the libs. which means better tests. Amir will summarise where things are with the thoughts around the 3.0 release and send to the list before the next time we discuss this.

--

AoB

• Irmin update: ThomasG is still working on getting feedback upstreamed and improving the API. The big thing missing is having a garbage collector. Over the weekend ThomasL transferred all his items to the browser and changed to using IndexDB which does not have a quota limit. ThomasL will write a blog post about this for others to follow. Noted that a JS backend for Irmin as separate lib might be good.

• State of Docs: A new user commented that they had a tricky time with documentation and that figuring out how to use our existing libs has been more difficult than necessary (specifically with Irmin). There's a pretty significant learning curve even if you know OCaml. In the case of Irmin, it would be much better if the examples themselves actually worked. In general, it would be good to be able to test such examples on an ongoing basis automatically).

• The next call is scheduled for Wednesday, 8th April, but there are indications that we may need to delay it by a day - Please add any agenda items you wish to discuss in advance and refer to the mailing list for actual details a day or so in advance.