All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.