Interesting to compare and contrast the approach taken by libreSSL and agl's BoringSSL (my own private fork is in the process of being replaced by BoringSSL, because it's not as hacky as my solutions).
I think I prefer BoringSSL's cmake/make process, because OpenSSL's build system is simply horrible, I've never liked it. But it doesn't do shared libraries yet, so I'm having to take the .a files and link them by hand (well, by script anyway). Not optimal, but better than having to rebase my own patches so frequently, and it's only a test box.
I love the sheer amount of renovation-via-demolition libreSSL's doing. OpenSSL really does have a terrifying amount of #if 0, crufty ciphers and code no-one ever wants to use.
By the way, you may as well take RC4 out: it's about to get another significant result...
fwiw, the current policy is that mere availability of crapto algorithms isn't the end of the world. This is clearly debatable (I'm not entirely happy with it myself), but the reality is that many people using crapto are stuck with it, and if one library doesn't offer it, they'll use another that does.
Like if no RC4 meant no youtube, I don't think we're quite popular enough to demand that youtube change ciphers.
I think I prefer BoringSSL's cmake/make process, because OpenSSL's build system is simply horrible, I've never liked it. But it doesn't do shared libraries yet, so I'm having to take the .a files and link them by hand (well, by script anyway). Not optimal, but better than having to rebase my own patches so frequently, and it's only a test box.
I love the sheer amount of renovation-via-demolition libreSSL's doing. OpenSSL really does have a terrifying amount of #if 0, crufty ciphers and code no-one ever wants to use.
By the way, you may as well take RC4 out: it's about to get another significant result...