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
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