Also, and not only, for the Best Practice badge, we should set up an official vulnerability report process for seL4.
So far, this has simply been by email to one fo the developers. That doesn’t necessarily have to change much, but it needs to be documented.
I propose to set up an email alias that goes to the subset of the technical steering committee that volunteers to be a point of contact for these. We should set up optional encryption for this for people who want to use it.
Any report should get a response within 14 days, and depending on what it is will either go to the bug tracker to be resolved or documented if it can’t/shouldn’t be resolved (e.g. things like Rowhammer), or, if it is for some reason sensitive, will be handled privately with the reporter until it can be made public.
ps: for those who are wondering, why can there be vulnerabilities in verified seL4? Because there are assumptions about the hardware that can be broken, like in Rowhammer, or not used correctly, such as making a mistake with cache coherency, and because there are unverified configurations of seL4 that can have bugs. People often would still like to deploy unverified configurations in systems, and we want to support that with at least the same level of confidence you can have in other well-engineered software.