In general, locally added roots are trusted above all else -- and will even override cert pinning on most systems. Thus, if a user were to manually re-add the Wosign or Startcom roots to the local Mozilla trust store, they would continue to be trusted.
Sounds about right, but one thing to keep in mind is that "Removal of root" is only one possible route Mozilla can go for. They could also revoke (root or intermediate) certificate(s) through OneCRL, and while I haven't tried this, my guess would be that OneCRL trumps locally-added roots.
That being said, the current plan is not to remove any of the roots (at least until all active certificates chaining up to those roots have expired), but rather not to trust certificates chaining to those roots with a notBefore date > October 21, 2016.
Yes, the Startcom roots are included in the set to be distrusted. Mozilla is allowing Startcom to re-apply sooner than Wosign, but both will have to go through the entire CA vetting process again, and Startcom will also have to prove it's no longer controlled by Wosign.
We use VirtualBox in our courses since it's a single platform that runs on all 3 major operating systems. Chromebooks are still an issue, but few enough people have those that we can basically just classify them as unsupported. There's still some setup effort, especially on Windows machines that ship with hardware virtualization disabled at the BIOS level, but it's a much simpler way to get 1000+ students up and running quickly than trying to have everyone setup local dev environments.
Although it will be interesting to see if anything in the recent dump shows them violating the terms of that license or committing other Wassenaar violations between 2014 when the EU implemented it and now.
This story has surfaced a few times now via various publications. I think the assertion that Wassenaar is the issue here is highly flawed.
First, since this student is operating in the UK and, as far as I can tell, is a UK citizen, the proposed US Wassenaar implementation and FAQs have no bearing on him. Instead, I belive he is just bound by the EU implmention of Wassenaar, which unlike the proposed US rules, more-or-less mirrors the original 2013 text exactly: http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX.... So any discussion related to what BIS is planning to do is irrelevant to this case. And even if he were a US-based US citizen, it would still be irrelevant since the US rules are still in the proposed stage and aren't even in effect yet.
Second, Wassenaar explicitly exempts anything "in the public domain", as well as all mass-market software, from control under the General Software Note. This is generally interpreted to include any open source code or even publically-available object code, as well as academic research publications.
Finally, the Wassenaar control mechanism for the Class 4 items operates as a secondary control. First it defines "Intrusion software" as:
"Software" specially designed or modified to avoid detection by 'monitoring tools', or to defeat 'protective countermeasures', of a computer or network-capable device, and performing any of the following: the extraction of data or information, from a computer or network-capable device, or the modification of system or user data; or the modification of the standard execution path of a program or process in order to allow the execution of externally provided instructions.
But it does not attempt to control "Intrusion Software" directly. Instead it goes on to control:
4.A.5: Systems, equipment, and components therefor, specially designed or modified for the generation, operation or delivery of, or communication with, "intrusion software".
4.D.4: "Software" specially designed or modified for the generation, operation or delivery of, or communication with, "intrusion software".
4.E.1.c: "Technology" for the "development" of "intrusion software".
So individual exploits such as the ones discussed here are not even controlled. Only software designed for the operation, delivery, or control of systems compromised or targeted by such exploits (e.g. think Metasploit, ignoring the open-source and mass-market exemption that likely apply to it).
So it seems like a reach to assert that Wassenaar would control the discussed research, and even if it did, the research could still be published and/or released to the general public without infringing Wassenaar under the General Software Note exemptions.
The issue here seems much more about an Ethics Boards that has little understanding of the ethics of best-practice coordinated disclosure or basic academic freedoms. Wassenaar and the proposed US implementation has many issues, but this doesn't seem to be one of them.
But isn't the blacklist you link to in the article specifically for queued TRIM? E.g. https://github.com/torvalds/linux/commit/9a9324d. SO either that blacklist has nothing to do with this issue (in which case it probably shouldn't be linked from the article), or it does, and we're talking about issues with queued TRIM.
