On Tue, Apr 10, at 10:48 ag wrote: > On Mon, Apr 09, at 02:49 Bruce Dubbs wrote: > > On 04/09/2018 02:18 PM, Richard Melville wrote: > > > > > Well, I disagree. Joel Sing has made it clear that he wants libressl to > > > be a drop-in replacement for openssl. He has also stated publicly that > > > he thinks opaque data structures (the basis of the openssl 1.1 API > > > change) are a good thing. It's openssl that has broken compatibility > > > between the 1.0 and the 1.1 APIs, and thus created issues with openssh, > > > not libressl. It is, therefore, unrealistic to expect libressl to > > > conform to the 1.1 API over night. Clearly, it is going to take some > > > considerable time. > > > > It has been two years. How much time do you think is reasonable? > > > > > As a corollary of the need for the original fork, we have seen how many > > > further openssl security breaches were discovered post fork, none of > > > which affected libressl. > > > > I wonder why there has been no mass exodus to libressl. It has been around > > from 2014. Do you have any ideas about that? > > > > I did read https://en.wikipedia.org/wiki/LibreSSL > > It does read like it was written by libressl or bsd developers. > > Tricky. But might be easy finally. > > Theo De Raadt might be an over[something] endless stream of consciousness > mind that simply can not keep his mouth shut, but is an expert in security. > > I mean, if there is group of people (this time on earth), on who the earth > could be set its trust to those matters (we are speaking here for the tls > stack > and the secure shell (okey?)) and undeniable by all, that would be him and his > friends on OpenBSD! > > But as i said the solution at the end might be finally easy. > > We just have to provide two different sets of instructions; one for openssl > and > one for libre. No big deal. Its not that simple as both can not coexist in the same namespace. The thing is that the sonames are identical and much of the API (if all, i don't know) but that doesn't certainly provides ABI compatibility. So all the libraries and applications should link against the specific library.
Now for us that means some choises: 1. we can just add a page for libressl and whereever refers openssl, we have additionally refer libressl. But there must be a big fat warning that either one or the other. (and also to wait for breakages when linking with libressl, for instance I use a patch to build the elinks web browser, but this is not going to be a big issue as there is a precedence and a source we can take patches) 2. use different namespaces. This should work. But it is not practical and can be a little bit complicated. We have to talk about using the LD_LIBRARY_PATH, when building and when running the applications. Personally someone can take this path but as book instructions again is not practical and can end up wasting our time anwsering questions 3. another copy of the book that will have libressl as the default tls layer. I can do this book in the summer when we are going to build lfs with Dimy, but I shouldn't be able to test as I use very little things already and its going to be worse with years, but we can do this with my son as an educational project My opininion is the first option or nothing but this is horrible and its a pity. Best, Αγαθοκλής -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
