Re: Remaining breakage on apr-1.7.x branch

[Eric Covener <co...@gmail.com>]

On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>
> Hello friends and collaborators,
>
> I'm still rather certain this change is ABI and API contract-breaking
> on the apr-1.7.x branch, which holds the project hostage for providing
> a well-understood security fix on the legacy branch. Such things
> can't persist, our individual maintenance branches must also observe
> semver, such that anyone could consume a maintenance branch and
> not be API nor ABI broken against the prior sub-version release;
>
> https://github.com/apache/apr/compare/1.7.0...1.7.x#diff-86c28ef8e95257a8d60ce73f3262290e91fc5ca3eb722144a6c99559ddf717cf
>
> I'd propose a radical solution, either all of include/* excluding most
> of private / arch/* have no adverse effects on a rebuild, or we revert
> the whole branch to the last stable release, in 7 days. Allow a 7 day
> window to reintroduce critical and desired changes that don't break
> our dev guidelines;
>
> https://apr.apache.org/versioning.html.
>
> All other questions were resolved at least 4 weeks ago, as can
> be observed from include/* changes which alter the incremental
> consumer's observations, github makes this simple;
>
> https://github.com/apache/apr/compare/1.7.0...1.7.x#
>
> So I think we are nearly ready 14 days from now to tag 1.7.1
> and solve this conundrum. If it can be proven than the existing
> 1.7.0 or 1.7.1 builds would be entirely compatible and not break
> developer's expectations when deployed against either 1.7.1
> or 1.7.0 in the next 7 days, my objection is withdrawn and we
> will tag this code in one week, not waiting for 2 weeks.
>
> Who wants to help prove up or down that it should persist and
> work out the back-out as needed? Otherwise I ask the project
> member's permissions to work from a new 1.7.x-rebuild branch
> for the following week based on 1.7.0, and replace 1.7.x with
> the 1.7.x-rebuild branch one week later.

Should we just back out r1896748 (ring strict aliasing thing) out at
this stage?  I think the radical solution is too labor intensive and
unlikely to progress.

Re: Remaining breakage on apr-1.7.x branch

[William A Rowe Jr <wr...@rowe-clan.net>]

On Tue, Sep 13, 2022 at 12:21 PM Ivan Zhakov <iv...@visualsvn.com> wrote:
>
> Btw I've recently backported several fixes to 1.7.x branch:
> [[[
>   *) Fix attempt to free invalid memory on exit when apr_app is used
>      on Windows. [Ivan Zhakov]
>   *) Fix double free on exit when apr_app is used on Windows. [Ivan Zhakov]
>
>   *) Fix a regression in apr_stat() for root path on Windows. [Ivan Zhakov]
> ]]]
>
> And CMake/GitHub Actions stuff.

Thanks for all of these! I'll proceed in the morning to tag 1.7.1, and
then will be
happy to mentor someone to tag 1.8.0 once we trust that this breaks nothing in
terms of minor versioning rev rules, and that the new features have maintainers.

Re: Remaining breakage on apr-1.7.x branch

[Ivan Zhakov via dev <de...@apr.apache.org>]

On Mon, 12 Sept 2022 at 17:21, William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> After deep study of the whole ring strict alias issue, I've come to
> the conclusion that
> the -resulting- binary is effectively the same, and my test case was
> swapping the
> apr .so files between builds of httpd 2.4.54 / apr 1.7.0 and httpd
> 2.4.x/ apr 1.7.x.
> Running httpd test, no errors were introduced, all binaries loaded and ran
> fine.
> Someone building Subversion might want to repeat that exercise.
>
> So this was entirely a work-around to ensure the grammar didn't escape
> notice
> when types and values were switched around in ways that a compiler might
> over-optimize. There were instances where -O3 could break apr at one point,
> and I'm wondering if this might have been that root cause?
>
> I think we can accept this very unusual (for a stable release branch)
> contortion,
> since code correctly compiled on either 1.7.0 or 1.7.branch appear to
> accomplish
> the same and are binary-stable, only using different syntaxes to get there.
>
> Any final thoughts before we simply release 1.7 branch as-is?
>
> I'm fine with both approaches.

Btw I've recently backported several fixes to 1.7.x branch:
[[[
  *) Fix attempt to free invalid memory on exit when apr_app is used
     on Windows. [Ivan Zhakov]
  *) Fix double free on exit when apr_app is used on Windows. [Ivan Zhakov]

  *) Fix a regression in apr_stat() for root path on Windows. [Ivan Zhakov]
]]]

And CMake/GitHub Actions stuff.

-- 
Ivan Zhakov

Re: Remaining breakage on apr-1.7.x branch

[William A Rowe Jr <wr...@rowe-clan.net>]

After deep study of the whole ring strict alias issue, I've come to
the conclusion that
the -resulting- binary is effectively the same, and my test case was
swapping the
apr .so files between builds of httpd 2.4.54 / apr 1.7.0 and httpd
2.4.x/ apr 1.7.x.
Running httpd test, no errors were introduced, all binaries loaded and ran fine.
Someone building Subversion might want to repeat that exercise.

So this was entirely a work-around to ensure the grammar didn't escape notice
when types and values were switched around in ways that a compiler might
over-optimize. There were instances where -O3 could break apr at one point,
and I'm wondering if this might have been that root cause?

I think we can accept this very unusual (for a stable release branch)
contortion,
since code correctly compiled on either 1.7.0 or 1.7.branch appear to accomplish
the same and are binary-stable, only using different syntaxes to get there.

Any final thoughts before we simply release 1.7 branch as-is?

Bill


On Wed, Sep 7, 2022 at 11:06 AM Eric Covener <co...@gmail.com> wrote:
>
> On Thu, Jul 28, 2022 at 12:59 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
> >
> > Hello friends and collaborators,
> >
> > I'm still rather certain this change is ABI and API contract-breaking
> > on the apr-1.7.x branch, which holds the project hostage for providing
> > a well-understood security fix on the legacy branch. Such things
> > can't persist, our individual maintenance branches must also observe
> > semver, such that anyone could consume a maintenance branch and
> > not be API nor ABI broken against the prior sub-version release;
> >
> > https://github.com/apache/apr/compare/1.7.0...1.7.x#diff-86c28ef8e95257a8d60ce73f3262290e91fc5ca3eb722144a6c99559ddf717cf
> >
> > I'd propose a radical solution, either all of include/* excluding most
> > of private / arch/* have no adverse effects on a rebuild, or we revert
> > the whole branch to the last stable release, in 7 days. Allow a 7 day
> > window to reintroduce critical and desired changes that don't break
> > our dev guidelines;
> >
> > https://apr.apache.org/versioning.html.
> >
> > All other questions were resolved at least 4 weeks ago, as can
> > be observed from include/* changes which alter the incremental
> > consumer's observations, github makes this simple;
> >
> > https://github.com/apache/apr/compare/1.7.0...1.7.x#
> >
> > So I think we are nearly ready 14 days from now to tag 1.7.1
> > and solve this conundrum. If it can be proven than the existing
> > 1.7.0 or 1.7.1 builds would be entirely compatible and not break
> > developer's expectations when deployed against either 1.7.1
> > or 1.7.0 in the next 7 days, my objection is withdrawn and we
> > will tag this code in one week, not waiting for 2 weeks.
> >
> > Who wants to help prove up or down that it should persist and
> > work out the back-out as needed? Otherwise I ask the project
> > member's permissions to work from a new 1.7.x-rebuild branch
> > for the following week based on 1.7.0, and replace 1.7.x with
> > the 1.7.x-rebuild branch one week later.
>
> Should we just back out r1896748 (ring strict aliasing thing) out at
> this stage?  I think the radical solution is too labor intensive and
> unlikely to progress.