Everything

php

Updating bundled libs (specifially, oniguruma) on 7.1/7.2

php.internals

Stas Malyshev

7 years ago

Hi!

I wonder if there's any reason not to update bundled oniguruma library
for 7.1/7.2. 7.1 one is ancient, 7.2 one is more recent but still
behind. There are numerous fixes, I am sure, and one functionality
improvement that allows to implement proper stack depth limiting
(https://github.com/php/php-src/pull/3997). Which also makes it kinda
security-relevant, which is why I am considering 7.1 too. The risk of
course is that there's some kind of BC break, but I haven't heard about
something like that. Did anybody?
Another risk is that newer library requires some new code to handle some
of the new options, and if we plug it into old code it may expose new
bugs (e.g. if you use some regex feature but our code can't handle it).
Quick scan through the release notes does not show anything like that,
but in theory it's possible.

Anybody has any thoughts on this?

Thanks,

--
Stas Malyshev
smalyshev@gmail.com

Remi Collet

7 years ago

Le 28/03/2019 à 22:50, Stanislav Malyshev a écrit :

> Hi!
>
> I wonder if there's any reason not to update bundled oniguruma library
> for 7.1/7.2. 7.1 one is ancient, 7.2 one is more recent but still
> behind. There are numerous fixes, I am sure, and one functionality
> improvement that allows to implement proper stack depth limiting
> (https://github.com/php/php-src/pull/3997). Which also makes it kinda
> security-relevant, which is why I am considering 7.1 too. The risk of
> course is that there's some kind of BC break, but I haven't heard about
> something like that. Did anybody?
> Another risk is that newer library requires some new code to handle some
> of the new options, and if we plug it into old code it may expose new
> bugs (e.g. if you use some regex feature but our code can't handle it).
> Quick scan through the release notes does not show anything like that,
> but in theory it's possible.
>
> Anybody has any thoughts on this?

7.1 have version 5.9.6
7.2 have version 6.3.0
7.3 have version 6.9.0 (latest is 6.9.1)
7.4 only use system library

As we encourage system library usage (default in 7.4), and if this raise
the minimal allowed version, this will create issue for 7.4

Ex
RHEL have 5.9
Debian have 6.1

I think we have to manage such change in a compatible way.
(feature availability tested in configure)

So, I don't think the bundled library (especially in 7.1) should be updated.

Remi


P.S. from downstream PoV, as soname is different is it possible to have
compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)

Stas Malyshev

7 years ago

Hi!

> 7.1 have version 5.9.6
> 7.2 have version 6.3.0
> 7.3 have version 6.9.0 (latest is 6.9.1)
> 7.4 only use system library
>
> As we encourage system library usage (default in 7.4), and if this raise
> the minimal allowed version, this will create issue for 7.4
>
> Ex
> 	RHEL have 5.9
> 	Debian have 6.1

Any reason why those are so far behind? 5.9 is from 2014!

> I think we have to manage such change in a compatible way.
> (feature availability tested in configure

This creates a very bad situation, where we can not implement security
improvements because we have to be compatible with a version of the
library that has been released 4.5 years ago.

Is there any reason why we prefer system library if actual system
library is not being properly maintained by packagers? I think if most
packagers neglect to keep with latest versions so much, we should keep
bundling it - otherwise, we are just exposing our users to security
issues and give them slower and buggier and feature-impaired library
despite being completely able to do better.

> P.S. from downstream PoV, as soname is different is it possible to have
> compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)

Not sure what you mean here, could you explain?

--
Stas Malyshev
smalyshev@gmail.com

Levi Morrison

7 years ago

On Fri, Mar 29, 2019 at 2:17 PM Stanislav Malyshev <smalyshev@gmail.com> wrote:

>
> Hi!
>
> > 7.1 have version 5.9.6
> > 7.2 have version 6.3.0
> > 7.3 have version 6.9.0 (latest is 6.9.1)
> > 7.4 only use system library
> >
> > As we encourage system library usage (default in 7.4), and if this raise
> > the minimal allowed version, this will create issue for 7.4
> >
> > Ex
> >       RHEL have 5.9
> >       Debian have 6.1
>
> Any reason why those are so far behind? 5.9 is from 2014!

Yes: Red Hat Enterprise Linux is intended to be *incredibly* stable.
It comes at the cost of always being a bit old.

> > I think we have to manage such change in a compatible way.
> > (feature availability tested in configure
>
> This creates a very bad situation, where we can not implement security
> improvements because we have to be compatible with a version of the
> library that has been released 4.5 years ago.

In many cases, Red Hat will backport security fixes to the old software.

> Is there any reason why we prefer system library if actual system
> library is not being properly maintained by packagers? I think if most
> packagers neglect to keep with latest versions so much, we should keep
> bundling it - otherwise, we are just exposing our users to security
> issues and give them slower and buggier and feature-impaired library
> despite being completely able to do better.

A lot of software will bundle unusual dependencies, and then have an
option to build using a given path, or to use the bundled extension. I
assume that's what we are doing with libonig? The person doing the
build should have the power to choose here.

> > P.S. from downstream PoV, as soname is different is it possible to have
> > compat package for library (v5.9 uses 2, v6.1 uses 4, v6.9 uses 5)
>
> Not sure what you mean here, could you explain?

I think Remi means that the .so files are versioned, so you end up
with libonig.so.2, libonig.so.4, and so on. Or alternatively they may
be named libonig2.so, libonig4.so, and so on. Either way, they can
coexist in the same library directory.

Stas Malyshev

7 years ago

Hi!

> As we encourage system library usage (default in 7.4), and if this raise
> the minimal allowed version, this will create issue for 7.4

We can do it in different way. Update the bundled versions, but not
raise the requirements. I can make the code adapt to old versions (at
the cost of functionality loss, of course).

> I think we have to manage such change in a compatible way.
> (feature availability tested in configure)
>
> So, I don't think the bundled library (especially in 7.1) should be updated.

If we make it work with old system libraries, what would be the reason
not to update the bundled ones?

--
Stas Malyshev
smalyshev@gmail.com