wireguard.lists.zx2c4.com archive mirror
 help / color / mirror / Atom feed
From: Gordon Bergling <gbe@freebsd.org>
To: Kyle Evans <kevans@freebsd.org>
Cc: freebsd-arch@freebsd.org,
	FreeBSD Hackers <freebsd-hackers@freebsd.org>,
	WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: Removing WireGuard Support From FreeBSD Base
Date: Wed, 17 Mar 2021 13:53:28 +0100	[thread overview]
Message-ID: <YFH7yIJ9OImHUwYO@lion.0xfce3.net> (raw)
In-Reply-To: <CACNAnaHR9Li0wPOjmwRk7jG76-AESoTt0QrrG_UVTrev38N=bQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3673 bytes --]

I am not sure, if the removal is a great idea, a removal from
releng/13 and stable/13 - possibly yes, but from main?

This is still -CURRENT and -CURRENT should be central place for development,
even if we have phabricator for review.

If the complete backout is happening, please don't forget the manual
page. I have spend a lot of time on it, while OpenBSD made a good
template.

--Gordon

On Tue, Mar 16, 2021 at 11:48:56AM -0500, Kyle Evans wrote:
> Hi,
> 
> You may have recently noticed some chatter around the internet about
> FreeBSD's in-kernel WireGuard implementation, and the work we've done
> on it in the last week.  You may have also noticed additional chatter
> afterwards with regards to the original implementation.  I'd like to give
> some context and information with regards to the current situation, as
> well as provide some insight into the future as one of the developers
> involved.
> 
> With regard to the original implementation, this will be my only
> commentary on the matter. I'm a developer, and I'm passionate
> about the work that I do- often to a fault. I've said some things that
> I regret; the accusations that Scott Long alluded to in an e-mail on FreeBSD
> mailing lists were indeed made by me, and his phrasing of what I
> said was much kinder than it could have been. These were mistakes,
> and I'm going to own that. However, my personal belief is that neither
> Netgate, pfSense, nor the original developer deserved the level of
> scorn and criticism that they've received in the past days from both the
> press and the community at large.
> 
> In the next day or so, I will be committing a removal of all WireGuard
> related bits from our 'main' branch, including the work that I recently
> committed. It will be followed up by a removal of the implementation
> from stable/13, and we will seek appropriate approval to remove it
> from releng/13.0 as well. Please, do not be concerned by any of this;
> this is being done with mutual support from all parties.
> 
> Did the original implementation have issues? Yes, it did. Are we
> certain that our new version -doesn't- have issues? I believe it
> doesn't, but it hasn't been through thorough enough review. We hacked
> on this for a week, and we all reviewed each others' work in the
> process. The problem is that this work, in particular, is a driver with fairly
> severe security implications. Review by "three developers working
> and beating on it" is not the higher bar that we should be
> holding this to. While I believed I was doing what's right for the
> community, it's become clear that what's right for the community is
> to take a step back and do this the right way.
> 
> Note that we're not dropping this effort. We will continue iterating
> on this out-of-tree, and we will go through the proper review
> channels. Folks will be unhappy in the interim because we're removing
> it right now, but in the end we will have a better FreeBSD because of
> it. There will be a kernel module available in ports at some point,
> but not before it's ready.
> 
> Moving forward, myself, members of Netgate, and members of the larger
> community *are* working together on strictly technical details. I urge
> anyone with an interest in reviewing the driver to also get in touch with me.
> Please, let's move forward as a community on this.
> 
> Thank you,
> 
> Kyle Evans
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

-- 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

  parent reply	other threads:[~2021-03-17 12:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-16 16:48 Removing WireGuard Support From FreeBSD Base Kyle Evans
2021-03-16 17:13 ` Jeffrey Walton
2021-03-16 17:37   ` Jason A. Donenfeld
2021-03-16 18:24     ` Nicolai
2021-03-16 17:30 ` Jason A. Donenfeld
2021-03-17 12:53 ` Gordon Bergling [this message]
2021-03-17 18:34   ` Jason A. Donenfeld
2021-03-17 19:29     ` Wireguard for FreeBSD without iflib Frank Behrens
2021-03-17 22:17       ` Jason A. Donenfeld
2021-03-19  7:47     ` Removing WireGuard Support From FreeBSD Base Gordon Bergling
2021-03-19 10:43       ` Evilham
2021-03-18 16:52 ` Kyle Evans
2021-03-18 16:57   ` Jason A. Donenfeld
2021-03-18 18:49 John Jacobs

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=YFH7yIJ9OImHUwYO@lion.0xfce3.net \
    --to=gbe@freebsd.org \
    --cc=freebsd-arch@freebsd.org \
    --cc=freebsd-hackers@freebsd.org \
    --cc=kevans@freebsd.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).