<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 11:43 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> This is a completely inappropriate comparison. LibreSSL is a cryptographic library. Creating a high-quality cryptographic library requires much more than eliminating buffer overruns (etc.).<br>
<br>
</span>What I don't get this what is the point of a "somewhat secure". Does<br>
it make a difference if takes 5 minutes of 5 hours to find a buffer<br>
overflow?<br>
<span class=""><br>
>> What allocator would you start with?<br>
>><br>
><br>
> We recently had a bunch of patches fixing issues found when fuzz testing LLVM with ASAN, and I thought that was a very positive development.<br>
><br>
<br>
</span>And today it is still way easier to crash llvm than lld. I posted two<br>
crashes with just what I noticed going on the list.  No one even<br>
posted an ELF that would crash lld.<br></blockquote><div><br></div><div>No, we were responding to the stated policy that it's intentional that LLD would crash/UB on certain inputs. We're debating that policy/intention.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It is really annoying how much people care about "security" to<br>
criticize my work, but never enough to send a patch. <a href="http://llvm.org/pr21466" rel="noreferrer" target="_blank">llvm.org/pr21466</a><br>
is open since Nov 2014. That is on the side of the project that should<br>
be handling broken files.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Would it end this thread if I went that way? Just say that there are<br>
bugs in lld and just not fix them for over a year?<br></blockquote><div><br></div><div>It would make a big difference if it was "Yes, these are bugs but not high priority for the current/active contributors to invest time in fixing (but happy to review patches to fix them, etc)" versus "these are not bugs/it's highly unlikely we'd accept patches to fix them".<br><br>Across the project we certainly prioritize bugs based on impact to those who are involved - we tend to fix Clang crash-on-valid faster than crash-on-invalid (certainly Kostya's been frustrated by lack of traction on some of the fuzzer findings - because few people need a security hardened LLVM/Clang, but generally "doesn't crash" is considered to be a valid/accepted goal, even if it's not hardened). Some bugs impact some users more than others, so are more important to some developers. 'tis the way of things.<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
Rafael<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div></div>