wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Jeffrey Walton <noloader@gmail.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel
Date: Fri, 17 Sep 2021 18:27:15 -0600	[thread overview]
Message-ID: <CAHmME9pvZ=Sj25cMJKQi+JH-PPN5AiiVSWe0eLnxVRSDtpDa+Q@mail.gmail.com> (raw)
In-Reply-To: <CAH8yC8=m72gvv3U-mbs5ib3eT79m+VNAX9s3muj63mHgoaD7Ew@mail.gmail.com>

Hello Jeff,

On Sun, Sep 12, 2021 at 3:55 PM Jeffrey Walton <noloader@gmail.com> 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.


  reply	other threads:[~2021-09-18  0:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-02 17:27 [ANNOUNCE] WireGuardNT, a high-performance WireGuard implementation for the Windows kernel Jason A. Donenfeld
2021-08-13 11:52 ` Jason A. Donenfeld
2021-08-13 15:58   ` Re[2]: " Hendrik Friedel
2021-08-13 16:09   ` Peter Whisker
2021-08-14 11:03   ` Phillip McMahon
2021-08-14 21:37   ` Morten Christensen
2021-08-16  8:15   ` nomad
2021-09-09 11:41   ` Jason A. Donenfeld
2021-09-12 21:06 ` Jason A. Donenfeld
2021-09-12 21:54   ` Jeffrey Walton
2021-09-18  0:27     ` Jason A. Donenfeld [this message]
2021-10-17  5:08 ` Jason A. Donenfeld

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHmME9pvZ=Sj25cMJKQi+JH-PPN5AiiVSWe0eLnxVRSDtpDa+Q@mail.gmail.com' \
    --to=jason@zx2c4.com \
    --cc=noloader@gmail.com \
    --cc=wireguard@lists.zx2c4.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).