[mirimir]

Quoting Linus Torvalds:[0]

> I see that Jason actually made the pull request to have wireguard included in the kernel.

> Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art.

0) https://lwn.net/ml/linux-kernel/CA+55aFz5EWE9OTbzDoMfsY2ez04...

Edit: fixed URL

[pfranz]

That's great to hear, but I wonder if anyone has insight on the rest of the article. Is this Zinc API a prerequisite for WireGuard to be included? Is the fact that Zinc won't support hardware encryption a no-go or is the expectation they give reasonable? Has the kernel had any large API refactoring similar the crypto/Zinc (I would assume it has)--how did they play out?

[caf]

There seems to be broad agreement for the need for a set of software crypto implementations with a straightforward synchronous, static dispatching API. The discussions seem to be mainly around code organisation and plumbing that API as an underlying implementation used by the dynamic dispatch asynchronous crypto API.

[zx2c4]

Right. So basically v2 of the Zinc patchset will address the nice points brought up on the list, and I think things should proceed nicely.

[rurban]

Jason: Any word on the name yet? My concern is the confusion with the existing my minizinc and flatzinc project, a standard constraint modeling language, which has nothing to do with crypto. There should be some better name for the Linux crypto lib.

[majewsky]

So what? Name clashes happen all the time. Before seeing this comment, I had never heard of minizinc and flatzinc. In fact, if you had asked me if Zinc clashes with anything, I'd have thought of Tinc (which is a VPN product, so roughly in the same space).

[mberning]

An incredible compliment to be sure.

[deelowe]

But in true Linus style, he just has to take a dig at another team at the same time to balance things out.

[foresto]

To be fair, his comment was not directed at another team, but at another body of code. (Two, actually.) The context makes it not merely a dig, but constructive feedback: "Those past projects have significant flaws, and here we have an example of how to do it right." If I were an OpenVPN or IPSec developer, I think I'd swallow my pride and take this valuable opportunity to learn how to improve my work.

[viraptor]

Or specifically as whole systems with multiple implementations. There's no "IPsec" code really.

[mirimir]

Sure. But isn't it a valid dig?

[deelowe]

I don't know. I'm sure the teams working on their tools had their reasons.

[swsieber]

There are reasons to have technical debt. Having reasonable reasons don't make the technical debt any easier to fix.

I don't think Linus' comment was directed at the author, it was at the code. Whatever the reason, the code he took a dig at is messier than wireguard.

[ryanlol]

You mean, each individual member of those teams had their reasons?

[deelowe]

Not sure. I'm not on the team, but I seriously doubt their intent was to write bad software. I know before ipsec existed there was nothing, so why not thank the individuals who worked on it for pioneering the effort in the first place?

[draw_down]

I think it's okay for him to be frank about things. We all don't like when he bites someone's head off; fine, that's not what he's doing here.

We're really at a point where people would prefer to discuss his tone rather than the content of what he says, even here.

[deelowe]

That's because he can't make a single comment on a thread without at least throwing a least a couple of backhanded insults in there.

[jwilk]

Fixed link: https://lwn.net/ml/linux-kernel/CA+55aFz5EWE9OTbzDoMfsY2ez04...

[mirimir]

Thanks :) I'm not sure how that happened.