Hello Jeff, On Sun, Sep 12, 2021 at 3:55 PM Jeffrey Walton <[email protected]> wrote: > One month to move into the next phase may be a bit tight for some > folks. 30 days is probably fine for a developer or standalone > installation, but some organizations cannot move that fast. > > I've worked in US Financial and US Federal, and some changes take > longer to approve. Some organizations have processes in place that > require approvals from management. It may take months to get a Change > Control Request approved. > > When I worked at Treasury a trivial change could take two or three > months and it required management signoffs and complete testing before > being released to the production network. Nearly everyone dreaded a > Change Control Request.
I'm not sure I really follow this line of reasoning here. You've divided the into two categories: A) "a developer or standalone installation" that is presumably frequently upgrading in order to have the latest in greatest. B) "US Financial and US Federal" and similar organizations for whom changes require extensive paperwork and reliability testing. For group (A), the gradual three phase rollout outlined in the initial email works very well, as it means each component gets an appropriate amount of testing depending on the phase, with related rollback controls. It's group (B) that you've raised a concern about. But, if each change for (B) requires paperwork and reliability testing, wouldn't _that_ procedure also catch issues? Obviously a downside of not updating like (A) does is that you miss timely security updates, but I assume that (B) argues that their slow processes of sign-offs and testing and paperwork increases reliability and accountability, which may well be more important for (B). And it would seem that those processes basically accomplish the same thing as the three phase plan that's available to group (A) does. So it doesn't seem like anybody is left out. Unless, of course, all those sign-offs and testing aren't _actually_ testing anything meaningful, and they're just a Brazilesque paperwork nightmare, in which case, with regard for neither security nor reliability, what does it matter either way? Anyway, there's no exact timeline of precisely 30 days. It will be a good time after nobody has reported a bug. While products have "go to market" deadlines, projects have the luxury of being on the "when it's ready" schedule, which means we don't need to rush. At the same time, I very much look forward to the reduced maintenance burden of no longer maintaining duplicate code paths in the wireguard-windows repo. The jd/remove-wintun branch has a commit that removes about a thousand lines, which isn't _that_ much, but those are lines that are a bit stressful in the sense that abstraction layers and duplicated code paths are common sources of bugs, so they require extra vigilance from me (and auditors). > It may be noteworthy... on Windows OSes, the trend is to move stuff > out of the kernel and into userspace to reduce risk. For example, > Microsoft moved parts of the GDI out of the kernel and into userspace. > So some folks may actually want the userland architecture to reduce > risk. I don't think it actually makes a practical difference in this case: the userspace tunnel service retained SeLoadDriverPrivilege so that it could *unload* Wintun when quitting. Besides, WireGuard was made to be implemented in operating system kernels; figuring out how to do that in a minimally scary way was an original thrust of the project. Linux, OpenBSD, FreeBSD, and now NT. Jason
