Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 8 Jul 2016 16:59:06 -0700
From:      Kevin Oberman <rkoberman@gmail.com>
To:        Grzegorz Junka <list1@gjunka.com>
Cc:        FreeBSD Ports ML <freebsd-ports@freebsd.org>
Subject:   Re: base components should always be default (Re: change in default openssl coming)
Message-ID:  <CAN6yY1szMOrBjiinbgjnOQB%2ByMhMmJaSCbTk=K1ZKxr584B0tw@mail.gmail.com>
In-Reply-To: <b4c87f59-fd30-19fd-5251-65c47720a0dc@gjunka.com>
References:  <D13290234BD20864405FC0B2@atuin.in.mat.cc> <f146f327-67f8-2ecf-21a9-b348dbe614c2@aldan.algebra.com> <b4c87f59-fd30-19fd-5251-65c47720a0dc@gjunka.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 8, 2016 at 12:20 PM, Grzegorz Junka <list1@gjunka.com> wrote:

>
> On 08/07/2016 16:29, Mikhail T. wrote:
>
>> On 08.07.2016 02:26, Mathieu Arnold wrote:
>>
>>> During this summer (sometime in August I think) I will be changing the
>>> default OpenSSL for the ports tree from the base system version to
>>> security/openssl.
>>>
>> The short answer is "Why?!" The longer reaction is: "please don't".
>>
>> Certainly not without a lengthy and exhaustive discussion (or flame-war,
>> if you will), which shall arrive at a consensus -- and, if it does not,
>> then no change shall happen.
>>
>> Generally, we should be eating our own dog-food -- using base-provided
>> components for everything by default where at all possible. If the base
>> OpenSSL is in some way(s) deficient, well, that's an argument for
>> updating the base. The base comes with not just the libraries, but withe
>> accompanying header-files -- meaning, the developers are free to use
>> those libraries. So the ports certainly should be doing just that.
>>
>> Our ports and the packages derived from them are part of FreeBSD -- and
>> the various components need to remain tightly integrated.
>>
>> Yes, I understand, you intend for there to remain an option, which the
>> holdouts like myself will be able to use to retain the old behavior. But
>> that's not good enough -- if the default packages will be built
>> differently, then bitrot will creep in and building against the base
>> will slowly become more and more difficult.
>>
>> I will also, because it goes with it, change the default GSSAPI from base
>>> to something else,
>>>
>> Sorry, what goes with what? Are you saying, Heimdal can't be built with
>> port's OpenSSL or vice versa?
>>
>>      -mi
>>
>>
>>
> The only reason I heard why base isn't updated with the proper package
> from ports is because of security implications. Older versions are more
> security-tested and therefore safer. If there is a vulnerability in the
> base it's much more hassle to update the base than ports.
>
> I don't have my opinion and sometimes it's annoying to not be able to use
> the base version, but putting everything into base is certainly an option
> if only the process of updating the base was light and quick enough. Is it
> like that now? Maybe with the incoming release cycle from FreeBSD-11?


Not really, though it is an issue. The issue with OpenSSL (and other
contributed code that is also part of ports) is that that the base is
limited to being updated with major releases if ABI changes are involved.
This keeps base well behind the current release and ports often require the
newer version in ports. It also means Building some ports with the base
system and some with the ports version leads to a chaotic situation where
one library is linked to the port shareable and another to the base one.
Then another port links to both of those libraries and that makes it
non-runnable as rtld won't load an image if it requires two different
versions of  shareable. Very awkward to clean up this mess. I know, having
had to do so a couple of times.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkoberman@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAN6yY1szMOrBjiinbgjnOQB%2ByMhMmJaSCbTk=K1ZKxr584B0tw>