Mailing List Archive: libapreq2 status & security release

libapreq2 status & security release

Jul 24, 2020, 3:22 AM

Post #1 of 5 (182 views)

The latest release of libapreq2 (v2.13) has an outstanding security
issue, CVE-2019-12412, which was fixed in apreq trunk at
https://svn.apache.org/r1866760 and subsequently assigned a CVE name
when a Debian user & maintainer noticed it was a security issue.

libapreq2 trunk was folded into httpd trunk and this fix was merged
there in https://svn.apache.org/r1867761 - but note this does not affect
httpd 2.4.x releases, which do not include libapreq2.

It looks to me like the last attempt to ship a libapreq2 standalone
release - v2.14 - in December 2016 stalled due to lack of PMC votes
https://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/201612.mbox/browse

libapreq2 has a v2.14 branch here
https://svn.apache.org/repos/asf/httpd/apreq/branches/v2.14/ and it
looks like the only substantive change between that branch is the above
security fix, plus r1867789.

It appears apreq used a one-branch-per-release repos structure which is
a bit odd but no reason not to follow that; I propose to follow
build/release to make a v2.15 release based off trunk, and then try to
get +3 PMC votes for that.

http://svn.apache.org/viewvc/httpd/apreq/trunk/build/RELEASE?revision=1772646&view=markup

Anything I'm missing?

Regards, Joe

Re: libapreq2 status & security release [ In reply to ]

covener at gmail

Jul 24, 2020, 4:03 AM

Post #2 of 5 (182 views)

Permalink

On Fri, Jul 24, 2020 at 6:29 AM Joe Orton <jorton@redhat.com> wrote:
>
> The latest release of libapreq2 (v2.13) has an outstanding security
> issue, CVE-2019-12412, which was fixed in apreq trunk at
> https://svn.apache.org/r1866760 and subsequently assigned a CVE name
> when a Debian user & maintainer noticed it was a security issue.
>
> libapreq2 trunk was folded into httpd trunk and this fix was merged
> there in https://svn.apache.org/r1867761 - but note this does not affect
> httpd 2.4.x releases, which do not include libapreq2.
>
> It looks to me like the last attempt to ship a libapreq2 standalone
> release - v2.14 - in December 2016 stalled due to lack of PMC votes
> https://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/201612.mbox/browse
>
> libapreq2 has a v2.14 branch here
> https://svn.apache.org/repos/asf/httpd/apreq/branches/v2.14/ and it
> looks like the only substantive change between that branch is the above
> security fix, plus r1867789.
>
> It appears apreq used a one-branch-per-release repos structure which is
> a bit odd but no reason not to follow that; I propose to follow
> build/release to make a v2.15 release based off trunk, and then try to
> get +3 PMC votes for that.
>

Thanks Joe. If someone tries a release I will sniff-test and vote.

Re: libapreq2 status & security release [ In reply to ]

ylavic.dev at gmail

Jul 24, 2020, 5:04 AM

Post #3 of 5 (182 views)

Permalink

On Fri, Jul 24, 2020 at 1:04 PM Eric Covener <covener@gmail.com> wrote:
>
> On Fri, Jul 24, 2020 at 6:29 AM Joe Orton <jorton@redhat.com> wrote:
> >
> > The latest release of libapreq2 (v2.13) has an outstanding security
> > issue, CVE-2019-12412, which was fixed in apreq trunk at
> > https://svn.apache.org/r1866760 and subsequently assigned a CVE name
> > when a Debian user & maintainer noticed it was a security issue.
> >
> > libapreq2 trunk was folded into httpd trunk and this fix was merged
> > there in https://svn.apache.org/r1867761 - but note this does not affect
> > httpd 2.4.x releases, which do not include libapreq2.
> >
> > It looks to me like the last attempt to ship a libapreq2 standalone
> > release - v2.14 - in December 2016 stalled due to lack of PMC votes
> > https://mail-archives.apache.org/mod_mbox/httpd-apreq-dev/201612.mbox/browse
> >
> > libapreq2 has a v2.14 branch here
> > https://svn.apache.org/repos/asf/httpd/apreq/branches/v2.14/ and it
> > looks like the only substantive change between that branch is the above
> > security fix, plus r1867789.
> >
> > It appears apreq used a one-branch-per-release repos structure which is
> > a bit odd but no reason not to follow that; I propose to follow
> > build/release to make a v2.15 release based off trunk, and then try to
> > get +3 PMC votes for that.
> >
>
> Thanks Joe. If someone tries a release I will sniff-test and vote.

+1

Re: libapreq2 status & security release [ In reply to ]

issac at issacg

Jul 24, 2020, 5:57 AM

Post #4 of 5 (182 views)

Permalink

> Anything I'm missing?
>
In theory, no. In practice I remember it being very difficult to test
properly last time I tried to RM, with a recent Perl and httpd.

I can't imagine it will be easier, so we should be aware, at time of
voting on the release, how much (thoroughly) it is actually being tested
pre-release...

Re: libapreq2 status & security release [ In reply to ]

jorton at redhat

Jul 24, 2020, 9:28 AM

Post #5 of 5 (182 views)

Permalink

On Fri, Jul 24, 2020 at 03:57:18PM +0300, Issac Goldstand wrote:
>
> > Anything I'm missing?
> >
> In theory, no. In practice I remember it being very difficult to test
> properly last time I tried to RM, with a recent Perl and httpd.
>
> I can't imagine it will be easier, so we should be aware, at time of voting
> on the release, how much (thoroughly) it is actually being tested
> pre-release...

The test suite passes though I needed to hack the Apache::Test stuff to
load mod_apreq.so which it doesn't seem to do OOTB.

But I am stuck on actually producing the release. "make release" runs:

perl build/version_check.pl > $(distdir)/PREREQUISITES
perl build/version_check.pl -version=2.16 > $(distdir)/META.yml

The first of these didn't work without r1880275 which I hope is correct,
but I cannot work out how to make the second work, it is failing with:

...
generated_by: build/version_check.pl
requires:
Use of uninitialized value $version in concatenation (.) or string at build/version_check.pl line 87.

and I'm not sure how to get further. Any ideas? I'm using Perl 5.30.3.

Will have to come back to this on Monday, sorry.

Regards, Joe