<p>It seems that the crypto performance gains <a href="https://blog.cloudflare.com/go-crypto-bridging-the-performance-gap/">announced recently</a> by Cloudflare may have hit an insurmountable licensing road block: <a href="https://groups.google.com/d/msg/golang-codereviews/m5QTnSUZU6c/Jc5yaMyF2_QJ">https://groups.google.com/d/msg/golang-codereviews/m5QTnSUZU6c/Jc5yaMyF2_QJ</a></p>
<hr/>**评论：**<br/><br/>hatessw: <pre><p>Can someone explain to me why BSD code cannot be relicensed by third parties as Go licensed? I thought the two were (unidirectionally!) compatible.</p>
<p>I mean, redistribution without (modified) source code (edit: even with redistribution limitations) is permitted under BSD as well, right? That is also a more limited form than the original code was released under.</p></pre>FUZxxl: <pre><p>The BSD license does <em>not</em> contain a grant to relicense the work. Each copy of a BSD licensed work is <em>directly</em> licensed from the authors. You cannot amend that license contract as a licensee. What is usually meant with “compatible” is that the restrictions imposed by one work are a subset of the restrictions imposed by the other work.</p></pre>bankslain: <pre><p>Yes, they can incorporate it into the Go codebase but Adam Langley says this:</p>
<blockquote>
<p>having bits of the Go repo under different licenses is sufficient unpleasant that counsel didn't want to entertain the idea.</p>
</blockquote></pre>egonelbre: <pre><pre><code>1 License == Complicated
2 Licenses == Complicated * Complicated
</code></pre></pre>davecheney: <pre><p>Please, only respond if you <em>are</em> a lawyer who specialises in intellectual property law. </p>
<p>Edit: thanks for the down votes, please continue to speculate wildly - 'cos that always helps. </p></pre>yegortimoschenko: <pre><p>You don't need to be a lawyer to understand a license. There is nothing cryptic and inaccessible to an ordinary person in a license. Probably some people want you to think another way by enforcing legalese in their EULAs, but most public licenses are not this way.</p></pre>_ak: <pre><blockquote>
<p>You don't need to be a lawyer to understand a license. There is nothing cryptic and inaccessible to an ordinary person in a license.</p>
</blockquote>
<p>I suppose you never tried to read and understand the GPL?</p></pre>yegortimoschenko: <pre><p>I suppose <em>you</em> never tried to read and understand the GPL. <a href="http://www.gnu.org/copyleft/gpl.html" rel="nofollow">Go ahead</a>, it will take no more than half an hour to read <em>and</em> understand it, at worst. I despise it and prefer <a href="http://opensource.org/licenses/ISC" rel="nofollow">ISC license</a> instead, by the way.</p>
<p>My point is, there is quite a lot of definitions, and there is a lot of rules that make GPL. It comes from the nature of the license. Each rule, if taken separately, is easily understandable. While it takes some time to read it, there is nothing inaccessible or cryptic to anyone who is able to read in English.</p>
<p>Edit: <code>wc</code> tells me that there are just 4614 words in GPL. It means it is just 37 times larger than this message.</p></pre>FUZxxl: <pre><p>The point about <em>understanding</em> is not about understanding the wording but about understanding how this is to be interpreted. For instance, certain clauses are invalid in certain countries. For instance, the GPL tries to define certain legal terms. That's not allowed in a software license in the US as the law specifies what language goes into a license. Also, some terms have a different meaning in legal contexts than you would expect. Lastly, you need to know existing rulings about the validity of the language in that license. Specifically for the GPL there have been cases where the judge strongly hinted that certain common interpretations of the GPL (e.g. that any library you link in needs to be GPL compatible) are probably incorrect.</p>
<p>It's naïve to assume that you can understand all aspects of a license just by reading the text.</p></pre>yegortimoschenko: <pre><p>Whatever you are smoking right now, I think you should share it.</p>
<p>You have just said that, in US, <a href="http://choosealicense.com/licenses/mit/" rel="nofollow">MIT</a>, <a href="http://choosealicense.com/licenses/apache-2.0/" rel="nofollow">Apache</a>, <a href="http://choosealicense.com/licenses/gpl-2.0/" rel="nofollow">GPL</a>, <a href="http://choosealicense.com/licenses/epl-1.0/" rel="nofollow">Eclipse</a>, <a href="http://choosealicense.com/licenses/mpl-2.0/" rel="nofollow">MPL</a>, and <a href="http://creativecommons.org/licenses/by/4.0/" rel="nofollow">Creative Commons</a> (including <a href="http://creativecommons.org/licenses/by/3.0/us/legalcode" rel="nofollow">US 3.0 port</a>) or any other license that contains term definitions (that means, pretty much any imaginable EULA, like <a href="http://www.adobe.com/legal/general-terms.html" rel="nofollow">Adobe's</a>) is invalid. </p>
<p>There are no magic legalese words to make a public license work. Even in US. Any text that specifies rights given to the public (copying, modification, or distribution) and conditions that you should meet in order to receive these rights (e.g. attribute the original author) in human language is fine. <a href="http://en.wikipedia.org/wiki/WTFPL" rel="nofollow">WTFPL</a> is a perfectly valid license, for that matter.</p>
<p>There is no list of reserved words in US law code.</p>
<p>I despise GPL, I really do, but it works as it is. In US it is successfully used to sue <a href="http://en.wikipedia.org/wiki/Free_Software_Foundation,_Inc._v._Cisco_Systems,_Inc." rel="nofollow">Cisco</a> and <a href="http://en.wikipedia.org/wiki/BusyBox#GPL_lawsuits" rel="nofollow">various small companies that have incorporated Busybox</a>.</p></pre>FUZxxl: <pre><blockquote>
<p>You have just said that, in US, MIT, Apache, GPL, Eclipse, MPL, and Creative Commons (including US 3.0 port) or any other license that contains term definitions (that means, pretty much any imaginable EULA, like Adobe's) is invalid. </p>
</blockquote>
<p>No, I haven't. Reading comprehension might help. I'm saying that the definition of <em>certain</em> legal terms is not allowed, specifically the <em>redefinition</em> of existing legal terms. For instance, a license is not allowed to define what a derivative work is.</p>
<blockquote>
<p>There are no magic legalese words to make a public license work. Even in US. Any text that specifies rights given to the public (copying, modification, or distribution) and conditions that you should meet in order to receive these rights (e.g. attribute the original author) is fine.</p>
</blockquote>
<p>No! That's simply not true. There are restrictions about what a license is allowed to contain in the US, let me look them up.</p>
<blockquote>
<p>I despise GPL, I really do, but it works as it is. In US it is successfully used to sue Cisco and various small companies that have incorporated Busybox.</p>
</blockquote>
<p>You might have misunderstood me. I'm not saying that the GPL is invalid, I'm saying that <em>certain parts</em> of the GPL are likely invalid (like some of the provisions for how to make derivative works) and others can be circumvented by clever interpretation. For instance, the GPL requires you to distribute with the work all libraries it requires except for “standard system libraries.” One can interpret this clause to mean “any library that is provided by the operating system,” and as Linux distributions ship a huge amount of libraries by default, one does not need to have any of these libraries licensed under a “non-discriminatory” license, essentially circumventing the clause that requires a derivative work to ship all dependencies.</p></pre>yegortimoschenko: <pre><blockquote>
<p>No, I haven't. Reading comprehension might help. </p>
</blockquote>
<p>Glad I was wrong on this point.</p>
<blockquote>
<p>For instance, a license is not allowed to define what a derivative work is.</p>
</blockquote>
<p>None of the listed licenses, by the way, contain such a definition.</p>
<p>Nor can I find such a rule being enforced in US law.</p>
<blockquote>
<p>No! That's simply not true. There are restrictions about what a license is allowed to contain in the US, let me look them up.</p>
</blockquote>
<p>It will be great if you provide a source for your point.</p>
<blockquote>
<p>For instance, the GPL requires you to distribute with the work all libraries it requires except for “standard system libraries.” One can interpret this clause to mean “any library that is provided by the operating system,” and as Linux distributions ship a huge amount of libraries by default, one does not need to have any of these libraries licensed under a “non-discriminatory” license, essentially circumventing the clause that requires a derivative work to ship all dependencies.</p>
</blockquote>
<p>There is quite a tight definition of it in the license:</p>
<blockquote>
<p>The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.</p>
</blockquote>
<p>I don't care, though. Maybe it is not accurate enough. I just don't believe certain parts of GPL are invalid because of overlapping of terms, that's what I am arguing about.</p></pre>_ak: <pre><p>You <em>think</em> you understand it, but you really don't. Even lawyers and law professors don't agree on what a lot of the details about it mean, and what the legal implications are.</p>
<p>What people <em>think</em> they know and understand about the GPL and its implications isn't necessarily what's true (if there is something like truth in things like that in the first place), but merely the narrative of the FSF.</p>
<p>That's the larger problem here: we developer (and yes, I'm aware that I'm generalizing here) think we know licensing and copyright law, and we ignoramuses attach licenses to pieces of software where we think we understand them, and from that, we quickly draw conclusions as soon as problems (like this one here) arise. Except that's just our naivité biting us in the ass. Because we know nothing about licenses, really, and their wider legal implications.</p></pre>yegortimoschenko: <pre><p>If you have a hard time understanding a relatively simple license (consider Apple EULAs), drop a line at rms@gnu.org with your question. The old guy is most likely nice enough to answer you within 48 hours.</p>
<p>I'm all ears as well. Stop walking around the issue. Cut the crap. What are the details no one can understand? Sources? Law precedents?</p></pre>computesomething: <pre><p>I did not downvote you, but really you don't need to be a specialized lawyer to answer basic software license questions.</p>
<p>The concept is not really rocket science, the author/owner of a piece of code has the right to set the <strong>conditions of use</strong> on said piece of code.</p>
<p>These 'conditions of use' is what we call a <strong>software license</strong>, no one except the author/owner can set these conditions, the author/owner on the other hand can offer said code under any number of conditions he/she want (this is where dual-licensing and re-licensing comes in).</p>
<p>As such, the answer to OP is that only Intel could choose to make their code available under the 'Go license' (either by dual licensing or re-licensing), since they are the owner of the code in question.</p></pre>iblueitagain: <pre><p>Not quite sure when you were elected as the decider of who can and can't post here. Just go about your day and leave the community to talk</p></pre>davecheney: <pre><p>Yay, software licences. </p>
<p><em>Cue dramatic Chipmonk</em></p></pre>bitmadness: <pre><p>Well, this sucks.</p></pre>staramper: <pre><p>Was it not possible to make this a separate package altogether? </p></pre>marcocharco: <pre><p>Yes, it can, but then we need an easy way to change the algorithms used in the TLS Package.</p></pre>jerf: <pre><p>You can copy & paste the whole library, for better or worse, then <code>import tls "github.com/cloudflare/fasttls"</code>. Modules aren't first-class citizens but you can relatively trivially swap them out wholesale at compile time, if you're in the mood. Of course you get transitive closure issues... if you're going to serve net/http over the new TLS you end up copying & pasting that too. It isn't quite as bad as simply "putting out your own custom Go" but you can end up with a lot of libraries. It works, though.</p></pre>marcocharco: <pre><p>That's a real pain compared to modifying the TLS library to allow external implementations..</p></pre>jerf: <pre><p>It depends on who you are. If you can contribute to the core Go code, yes, it is. If you can not, it turns out you'll find my approach a lot easier than changing the core Go code....</p></pre>kodemizer: <pre><p>It seems like there is an opportunity here for someone to make a patch / repo so end-users can compile go with this improvement outside of the main source-tree. </p>
<p>It would be an ugly work around certainly, but still would be worth it for those of us who do a lot of crypto with go. </p>
<p>Alternatively perhaps CloudFlare can hire someone to do a clean-room re-implementation. </p></pre>klauspost: <pre><blockquote>
<p>It seems like there is an opportunity here for someone to make a patch / repo [...]</p>
</blockquote>
<p>This is what cloudflare is currently doing at <a href="https://github.com/cloudflare/go">cloudflare go fork</a>. However, having to use an unofficial go build is just a nightmare.</p></pre>kodemizer: <pre><p>Ah, I didn't realize they already had that. I know, it's very suboptimal. Better than nothing I suppose. </p></pre>anacrolix: <pre><p>There's a lot of justification for it though. There are lots of boneheaded stubborn decisions made for the standard Go that everyone endures. It's a compiled language, this isn't necessary.</p></pre>bat_country: <pre><p>It may take a while but I can't imagine why Intel would not let them relicense the code. It's in their interest to have things run faster on their processors. </p></pre>anoland: <pre><p>From what I understand from the thread, there is an incompatibility between Apache license and BSD license. Can someone enlighten me?</p></pre>yegortimoschenko: <pre><p>It is a flawed idea <a href="https://go-review.googlesource.com/#/c/8968/2/src/crypto/elliptic/p256_asm_amd64.s" rel="nofollow">to have an assembly implementation of crypto algorithm</a> in a modern language.</p>
<p>Edit: And yes, there is nothing unsurmountable <a href="https://go-review.googlesource.com/#/c/8968/2/src/crypto/elliptic/p256_asm_amd64.s" rel="nofollow">in Intel's BSD license</a>: </p>
<blockquote>
<p>We at CloudFlare can remove anything, but I am afraid that the Intel notice got to stay. It comes with BSD license.</p>
</blockquote>
<p>The same thing happens in number of files in Go: <a href="https://github.com/golang/go/blob/fd392ee52b984e655390ad9147c9fe95e82bc459/src/cmd/5l/l.go" rel="nofollow">1</a> <a href="https://github.com/golang/go/blob/8a3132dd5ec1e1ffcad1dfdb33d98ea9b134cd1d/src/cmd/6g/reg.go" rel="nofollow">2</a> <a href="https://github.com/golang/go/blob/b986f3e3b54499e63903405c90aa6a0abe93ad7a/src/cmd/internal/obj/ar.go" rel="nofollow">3</a> </p>
<p>The only problem Russ Cox has is there is no mention of the type of license:</p>
<blockquote>
<p>This is not okay. This is a copyright notice without a license giving the terms of use. I know agl@ is working with you on resolving this, but the final commit absolutely must make the situation in this file clearer than these two lines.</p>
</blockquote>
<p>He explicitly says that they <em>try to avoid</em> additional notices, not that it stops a patch from being merged:</p>
<blockquote>
<p>Also, we try to avoid additional notice requirements. The best way to get this code submitted would be to make it covered by the existing CLAs. In particular, if you work for CloudFlare then the right thing to do for your part of this code is to get CloudFlare to do a CLA and then remove the Copyright CloudFlare line below.</p>
</blockquote>
<p>Edit 2: Reddiquette, anyone? It is not like I don't have a point. Modern crypto algorithms, including ChaCha20-Poly1305 <a href="http://bxr.su/OpenBSD/lib/libssl/src/crypto/evp/e_chacha20poly1305.c" rel="nofollow">don't have an assembly implementation</a>. Nor does <a href="http://bxr.su/OpenBSD/lib/libssl/src/crypto/chacha/chacha.c" rel="nofollow">ChaCha</a> and <a href="http://bxr.su/OpenBSD/lib/libssl/src/crypto/poly1305/poly1305.c" rel="nofollow">Poly1305</a> separately.</p>
<p>Or, for example, <a href="https://github.com/jedisct1/libsodium" rel="nofollow">Libsodium</a> doesn't come with any assembly.
<a href="http://nacl.cr.yp.to" rel="nofollow">NaCl</a> generates assembly from <a href="http://cr.yp.to/qhasm.html" rel="nofollow">their own qhasm</a>.</p>
<p>Even <a href="https://github.com/ARMmbed/mbedtls" rel="nofollow">PolarSSL</a> (which is now mbedTLS) doesn't come with assembly.</p></pre>creddit_is_due: <pre><blockquote>
<p>flawed idea</p>
</blockquote>
<p>I don't think assembly implementations of crypto are bad. Processor manufacturers added processor instructions for AESENC and AESDEC for precisely this reason - performance improvements of 10-30x. Since it's such a small portion of the entire go codebase I don't think it's much of an issue.</p></pre>Rainfly_X: <pre><p>Also, consistent timing is necessary to prevent timing attacks. There are things that you always want to have the same level of (in)efficiency - classic example is string comparison. If you bail out early as soon as you know the compare failed (usually the correct and fast way), an attacker can statistically determine how close he was to success, and incrementally deduce the secret value. It's one of the rare things in hacking that actually works like JASON stealing the nuclear launch codes.</p>
<p>Many of these consistent-time algorithms can't be implemented reliably in C, let alone Go, because optimization is so ingrained in the way compilers work, and it's only a very small area where you want them turned off. Assembly is the perfect choice, or at least as good as it gets. On a modern processor, even machine code is a high-level language subject to god knows what optimization and RISC-ification before it gets executed, although it's mostly crypto engineers that hate this, and everyone else is happy to accept the speed boost.</p>
<p>There's actually a source for that last part, but I'm on mobile, so hopefully someone else can find and post it.</p></pre>creddit_is_due: <pre><p>Thank you. I really should have pointed this out as well - security is more important than performance, after all. Vlad Krasnov, the author of this patch explained it somewhere as well.</p></pre>JexerGIT: <pre><blockquote>
<p>works like JASON stealing the nuclear launch codes</p>
</blockquote>
<p>Are you talking about <a href="https://www.youtube.com/watch?v=tGNBdjVO04Y" rel="nofollow">Joshua searching for the code</a>?</p></pre>Rainfly_X: <pre><p>Yep, misremembered the name of the sentient computer. Thanks for the correction and link.</p></pre>yegortimoschenko: <pre><blockquote>
<p>If you bail out early as soon as you know the compare failed (usually the correct and fast way), an attacker can statistically determine how close he was to success, and incrementally deduce the secret value.</p>
</blockquote>
<p>Avoid that by turning off compiler optimizations (cc -O0) for source code that contains crypto algorithms.</p>
<p>What you're telling is more painful. If there are assembly implementations only for popular architectures (amd64/i386), and the original implementation contains a timing attack vulnerability, then all other architectures (arm, sparc, mips, you name it) fallback to the original implementation and become subject to timing attacks.</p>
<p>Even if there is an implementation of every crypto algorithm for every single architecture (which is hardly maintainble), assembly is less readable and more prone to human errors. It is easier to skip a bug in assembly during an audit than in C. And using assembly complicates porting.</p>
<p>Edit: wording</p></pre>Rainfly_X: <pre><p>Found the article I was talking about: <a href="http://blog.erratasec.com/2015/03/x86-is-high-level-language.html?m=1" rel="nofollow">http://blog.erratasec.com/2015/03/x86-is-high-level-language.html?m=1</a></p>
<p>What I'm talking about is more frequently necessary on absurdly microcoded architectures like x86, and does not apply to every algorithm. We <em>usually</em> don't need encryption to be constant time so much as constant length, for example, which is why compression and encryption can be such a fatal combination.</p>
<p>However, because of the popularity of architectures like x86, we still frequently have to deal with situations where even assembly is challenging to defend against timing attacks, and in those cases, working in C would be like performing heart surgery with boxing gloves on.</p></pre>yegortimoschenko: <pre><blockquote>
<p>[...] and in those cases, working in C would be like performing heart surgery with boxing gloves on.</p>
</blockquote>
<p>False. When you are using "cc -O0", C to assembly translation is straightforward. Sometimes you probably want audit "cc -O0 -S" output to check for assembly representation and timing attacks, but that's it.</p></pre>Rainfly_X: <pre><blockquote>
<p>When you are using "cc -O0", C to assembly translation is straightforward.</p>
</blockquote>
<p>Only to audit. If you really need to use instructions that the compiler wouldn't normally use, like CMOV, you may have to bend over backwards to get the compiler to comply, and those workarounds may not be portable between compilers or compiler versions.</p></pre>yegortimoschenko: <pre><p>I believe using CMOV in a crypto algorithm inevitably leads to a timing attack vulnerability.</p></pre>Rainfly_X: <pre><p>Did you not read the blog by a professional security researcher, who gets paid to make this stuff work reliably? Let me quote it for your convenience:</p>
<blockquote>
<p>One solution to these problems is the CMOV, "conditional move", instruction. It's like a normal "MOV" instruction, but succeeds or fails based on condition flags. It can be used in some cases to replace branches, which makes pipelined code more efficient in some cases. Currently, it takes constant time. When moving from memory, it still waits for data to arrive, even when it knows it's going to throw it away. As Linus Torvalds famously pointed out, CMOV doesn't always speed up code. However, that's not the point here -- it does make code execution time more predictable. But, at the same time, Intel can arbitrarily change the behavior on future processors, making it less predictable.</p>
</blockquote>
<p>You're not only wrong, you're perfectly opposite of correct. Even better, this blunder was completely preventable, if you had read the article I posted, which is fairly short and interesting.</p></pre>yegortimoschenko: <pre><p>Unfortunately for your rant, I have read this article a while ago, way before you have mentioned it, while it still was at HN top. I forgot that the article mentions CMOV being <em>practically</em> constant time instruction in this article, though.</p>
<p>There is nothing that stops CMOV from being a variable time instruction if one of operands is a memory location. It is not time-proof to use CMOV in a crypto algorithm. You shouldn't rely on this behavior since it is not defined.</p></pre>talammadi: <pre><p>Couldnt disagree more with the assembly comment. </p></pre>
