On 22 April 2018 at 16:51, Bruce Dubbs <bruce.du...@gmail.com> wrote:
> On 04/22/2018 10:32 AM, ag wrote: > >> 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: >>>> >>> > 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. >> > > Interesting. > > 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, >> > > What is this about? What is 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 opinion is the first option or nothing but this is horrible and its a >> pity. >> > > I agree with the do nothing option. I wasn't going to be drawn into this discussion again as it appears that Bruce's mind is already made up, however, I think that a summary is worth the effort. Taking openssh as the starting point, the discussion revolved around which of the two TLS libraries, openssl or libressl, should be linked to it. Openssh is an openbsd project, so which makes more logical sense: another openbsd project: libressl. or openssl from an entirely separate developer team with a heavily patched openssh? Another point that I'd like to make is that since 2014 openssh does not need *any* additional TLS library as it already contains the AES-CTR, ED25519, ECDH, and ChaCha20 cryptos, where elliptic curve is more secure, and faster, than RSA/DSA. An added advantage is that building openssh in this manner produces a much smaller code base, which is always better. Compiling openssh without the patch, and using -- without-openssl worked for me. Richard
-- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
