Thread (146 messages) flat view 146 messages, 16 authors, 2018-11-13

Re: [PATCH net-next v6 00/23] WireGuard: Secure Network Tunnel

From: Eric Biggers <ebiggers@kernel.org>
Date: 2018-10-03 06:49:57
Also in: linux-crypto, lkml

On Tue, Oct 02, 2018 at 02:22:47PM +0200, Jason A. Donenfeld wrote:
On Tue, Oct 2, 2018 at 8:04 AM Ard Biesheuvel [off-list ref] wrote:
quoted
Also, I still think the name Zinc (zinc is not crypto/) is needlessly
divisive and condescending, and unsaying it (in v2 and up) doesn't
really work on the Internet (especially since you are still repeating
it in your conference talk.)
Jason, you seem to hate the existing crypto framework with passion,
and the name reflects that.
It's not divisive or condescending. I don't hate the existing
framework with a passion -- this is patently false. The name even with
its original acronym doesn't imply anything essentially negative. I
see that you've repeatedly misinterpreted it this way -- which is why
I removed that from v2 for the avoidance of doubt --  but that doesn't
change the fact that its proper interpretation is not a condescending
or divisive one.

Look, people love to bikeshed about names. I'm sure you'll be able to
CC-in a large crew of people who have opinions in one way or another,
and this thread could begin to have many voices on that front or on
multiple fronts. There are real benefits of sticking with the name
I've given to the library I've spent enormous amounts of time writing.
And so I'm going to stick with Zinc, since that's why our library is
called. Sorry. We can talk about this at Plumbers in Vancouver if you
want, but I think you're not going to get very far with a mailing list
naming bikeshed.
It's not really about the name, though.  It's actually about the whole way of
thinking about the submission.  Is it a new special library with its own things
going on, or is it just some crypto helper functions?  It's really just the
latter, but you've been presenting it as the former, which is causing a lot of
unnecessary confusion and controversy.  And I think that largely because you've
started from that perspective, you've ended up with some oddities like your own
directories in lib/ and include/ separate from the other existing crypto helper
functions, and proposals to maintain it completely separately from the existing
crypto code including having a separate git tree and separate upstreaming path.

For example, we already have include/crypto/.  What's the difference between
include/crypto/ and include/zinc/?  How do users know whether to include e.g.
<crypto/chacha20.h> rather than <zinc/chacha20.h>?  And are users going to
remember and understand that "zinc" actually means "crypto" but not really?  It
would be much more straightforward and intuitive if we just had
<crypto/chacha20.h>, and your new helper functions were declared in there.

Dismissing these concerns as bikeshedding about the name is missing the point.

- Eric
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help