Hi,
On Wed, Sep 25, 2019 at 10:29:45AM +0200, Jason A. Donenfeld wrote:
> I've long resisted the idea of porting to the existing crypto API,
> because I think there are serious problems with it, in terms of
> primitives, API, performance, and overall safety. I didn't want to
> ship WireGuard in a
Hi Dave,
On Wed, Sep 25, 2019 at 12:03 PM David Miller wrote:
> I didn't say "must" anything, I suggested this as a more smoothe
> and efficient way forward.
s/must/should/g? However it's characterized, I think your jugements
and opinions are generally sound, and I intend to put them into
action
From: Bruno Wolff III
Date: Wed, 25 Sep 2019 04:17:00 -0500
> Are there going to be two branches, one for using the current API and
> one using Zinc?
This is inapproprate to even discuss at this point.
Let's see what the crypto based stuff looks like, evaluate it,
and then decide how to proceed
From: "Jason A. Donenfeld"
Date: Wed, 25 Sep 2019 10:29:45 +0200
> His viewpoint has recently solidified: in order to go upstream,
> WireGuard must port to the existing crypto API, and handle the Zinc
> project separately.
I didn't say "must" anything, I suggested this as a more smoothe
and effi
Are there going to be two branches, one for using the current API and one
using Zinc?
"Jason A. Donenfeld" writes:
> Hi folks,
>
> I'm at the Kernel Recipes conference now and got a chance to talk with
> DaveM a bit about WireGuard upstreaming. His viewpoint has recently
> solidified: in order to go upstream, WireGuard must port to the
> existing crypto API, and handle the Zinc pr
Hi folks,
I'm at the Kernel Recipes conference now and got a chance to talk with
DaveM a bit about WireGuard upstreaming. His viewpoint has recently
solidified: in order to go upstream, WireGuard must port to the
existing crypto API, and handle the Zinc project separately. As DaveM
is the upstream
7 matches
Mail list logo
