Hi Willy,

On Fri, Jan 26, 2018 at 6:21 PM, Willy Tarreau <w...@1wt.eu> wrote:

> Hi Igor,
>
> On Fri, Jan 26, 2018 at 05:07:10PM +1100, Igor Cicimov wrote:
> > Hi Willy,
> >
> > On Fri, Jan 26, 2018 at 3:47 PM, Willy Tarreau <w...@1wt.eu> wrote:
> >
> > > On Fri, Jan 26, 2018 at 01:26:35AM +1100, Igor Cicimov wrote:
> > > > Or you meant using the haproxy 16.04 image actually. Ok, another
> option
> > > is
> > > > to compile it myself with the openssl version I have atm.
> > >
> > > What mostly matters is the version used to *build* haproxy, because
> > > some features have to be known at build time. If you pick an haproxy
> > > package made for a more recent distro using 1.0.2 or later, it will
> > > enable ALPN. Whether or not it will work on your current distro with
> > > your locally rebuilt openssl is a big question of course.
> > >
> > > You should definitely avoid building openssl yourself, it's the best
> > > way to forget about upgrading it when a vulnerability is disclosed.
> > > However if you're already doing it for other reasons it's different
> > > and then maybe you can build your own haproxy with this openssl
> > > version. But as Lukas said, the easiest solution is to upgrade the
> > > distro :-)
> > >
> > > Willy
> > >
> >
> >
> > So that's actually what my initial question was aiming at. While building
> > the deb archive for ubuntu trusty lets say doesn't it make sense to build
> > it using the latest stable openssl 1.0.2 just for the sake of the
> > features?
>
> I don't know what version ships in standard with this distro, but it makes
> sense to me that the packages that are built for a distro work with the
> distro's default package versions and do not require some hacks by the
> user. So if the distro uses 1.0.2 by default it would make sense. If it
> uses 1.0.1, it wouldn't make sense to add an extra dependency on an
> external, possibly less maintained, package. But that's just my opinion,
> I'm not a distro packager. However that's the type of issues we've had to
> deal with in our enterprise version since users expect the packages to work
> by default and a few advanced users also want the best features which are
> unfortunately not compatible with the default distro :-/ And recently we've
> seen a progress in the right direction (eg with RHEL 7.4 IIRC) though that
> breaks again the compatibility with users of older packages!
>
> I really think that the whole mess around this is caused by the fact that
> H2 requires ALPN which was not present in the openssl version shipped with
> most distros when it was released, and that the lack of visibility of any
> future long term supported openssl version doesn't encourage distro vendors
> to provide large scale upgrades.
>
> Willy
>

​Yeah you are absolutely right here please scrap my previous comment which
totally doesn't make any sense :-( I guess it is more showing my
frustration with exactly what you described in the last paragraph.

Reply via email to