Re: release?

[Dave Fisher]

> On Aug 31, 2021, at 4:12 AM, Daniel Ruggeri  wrote:
> 
> 
> On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>> 
>> Le 30/08/2021 à 13:53, Eric Covener a écrit : 
>>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org 
>>>   
>>>  wrote: 
 In what state is our release handling? Given someone holding my hand, 
 could I do it? Or is it better to look someone over the shoulder while he 
 does it? 
>>> If there is an over-the-shoulder session I would like to tag along.  I 
>>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex. 
>>> Otherwise if you just want to struggle through it I can tag along but 
>>> I have no experience. 
>> 
>> I can give another try with my limited experience. 
>> 
>> I definitively would like to add a --dry-run option for all scripts so that 
>> they can be run for learning purpose without the fear of un-expected impact 
>> on svn. 
> FWIW, the announce.sh script which collates all the security "stuff" and 
> sends the announce emails drops the user to a shell to inspect/examine what 
> WILL happen before actually doing anything. Any non-zero return code of that 
> shell will abort the process. I used the heck out of that several times :-)
> 
> 
> 
>> 
>> Existing scripts are not that easy to read at first, but are understanbdable 
>> and followinghttp://httpd.apache.org/dev/release.html#how-to-do-a-release 
>>  helps a lot. 
>> The scripts should also be tweaked because of the latest changes in several 
>> places (at least web site update (now on github) and CVE announcement (if 
>> any) now that part of the process is handled elsewhere). 
>> 
> 
> +1
> 
> To my knowledge, the publishing of the site and overhaul of the new CVE 
> process are the things requiring updates.
> 

The JSON files for the release’s CVEs should be committed here: 
https://github.com/apache/httpd-site/tree/main/content/security/json 
 : 
https://gitbox.apache.org/repos/asf?p=httpd-site.git;a=tree;f=content/security/json;hb=HEAD
 



> -- 
> Daniel Ruggeri
>> The CVE announcement should be much easier, now that we have a "Send these 
>> Emails" on cveprocess.a.o. This should simplify part of the process where we 
>> were preparing some scripts to send the announcement emails. 
>> 
>> I've been lacking time for httpd since many weeks, but I should be able to 
>> RM next week if needed. 
>> 
>> CJ 
>> 
>>> Also: Anyone who has a showstopper to delay a release (even if not yet 
>>> proposed) please add it to 2.4.x STATUS so we can get things in order. 
>>> 

Re: release?

[Ruediger Pluem]

On 8/31/21 8:57 PM, Christophe JAILLET wrote:
> 
> Le 31/08/2021 à 20:25, Eric Covener a écrit :
>>
>> Should we think about reverting the recent mod_unique_id changes?  It
>> seems like that was noticed pretty quickly but I think the current
>> problem is still not well understood. Meanwhile the original problem
>> on the old codebase wasn't widely reported.
> 
> +1
> 
> We can also easily narrow the time window where duplicate can be generated by 
> just reordering the previous code.

Yes, looks like the old code base was "better". So let's do the improvement you 
mention and take some time for
reviewing the rewrite proposals that have been made on the Github PR.

Regards

Rüdiger

Re: release?

[Christophe JAILLET]

Le 31/08/2021 à 20:25, Eric Covener a écrit :


Should we think about reverting the recent mod_unique_id changes?  It
seems like that was noticed pretty quickly but I think the current
problem is still not well understood. Meanwhile the original problem
on the old codebase wasn't widely reported.


+1

We can also easily narrow the time window where duplicate can be 
generated by just reordering the previous code.


CJ

Re: release?

[Eric Covener]

On Mon, Aug 30, 2021 at 12:41 PM Yann Ylavic  wrote:
>
> On Mon, Aug 30, 2021 at 1:54 PM Eric Covener  wrote:
> >
> > Also: Anyone who has a showstopper to delay a release (even if not yet
> > proposed) please add it to 2.4.x STATUS so we can get things in order.
>
> I think that BZ 65519 and 65521 are showstoppers, I'm waiting for
> feedbacks from the OP to commit to trunk and propose the backport, but
> if it lasts too long I'll do it anyway..

+1, that POLLHUP one was one I was thinking of.

Should we think about reverting the recent mod_unique_id changes?  It
seems like that was noticed pretty quickly but I think the current
problem is still not well understood. Meanwhile the original problem
on the old codebase wasn't widely reported.

Re: release?

[ste...@eissing.org]

> Am 30.08.2021 um 22:53 schrieb Christophe JAILLET 
> :
> 
> 
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org  
>> wrote:
>>> In what state is our release handling? Given someone holding my hand, could 
>>> I do it? Or is it better to look someone over the shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
> 
> I can give another try with my limited experience.
> 
> I definitively would like to add a --dry-run option for all scripts so that 
> they can be run for learning purpose without the fear of un-expected impact 
> on svn.
> 
> Existing scripts are not that easy to read at first, but are understanbdable 
> and following http://httpd.apache.org/dev/release.html#how-to-do-a-release 
> helps a lot. The scripts should also be tweaked because of the latest changes 
> in several places (at least web site update (now on github) and CVE 
> announcement (if any) now that part of the process is handled elsewhere).
> 
> The CVE announcement should be much easier, now that we have a "Send these 
> Emails" on cveprocess.a.o. This should simplify part of the process where we 
> were preparing some scripts to send the announcement emails.
> 
> I've been lacking time for httpd since many weeks, but I should be able to RM 
> next week if needed.

I would like to look over your shoulder/help where I can. Maybe Eric can make a 
WebEx for us - that would make following along much easier, I guess.

Looking at the description link (thanks) I see that there are still a lot of 
"manual" things involved. And a "--dry-run" is definitely a thing we want. Will 
have a look at those scripts in the next days, to see what I can add here.

- Stefan
> 
> CJ
> 
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>> 

Re: release?

[Daniel Ruggeri]

On 8/30/2021 3:53 PM, Christophe JAILLET wrote:
>
> Le 30/08/2021 à 13:53, Eric Covener a écrit :
>> On Mon, Aug 30, 2021 at 7:36 AM ste...@eissing.org
>>  wrote:
>>> In what state is our release handling? Given someone holding my
>>> hand, could I do it? Or is it better to look someone over the
>>> shoulder while he does it?
>> If there is an over-the-shoulder session I would like to tag along.  I
>> am flexible on time of day but I am GMT+4 (EDT).  I can host on webex.
>> Otherwise if you just want to struggle through it I can tag along but
>> I have no experience.
>
> I can give another try with my limited experience.
>
> I definitively would like to add a --dry-run option for all scripts so
> that they can be run for learning purpose without the fear of
> un-expected impact on svn.

FWIW, the announce.sh script which collates all the security "stuff" and
sends the announce emails drops the user to a shell to inspect/examine
what WILL happen before actually doing anything. Any non-zero return
code of that shell will abort the process. I used the heck out of that
several times :-)


>
> Existing scripts are not that easy to read at first, but are
> understanbdable and following
> http://httpd.apache.org/dev/release.html#how-to-do-a-release helps a
> lot. The scripts should also be tweaked because of the latest changes
> in several places (at least web site update (now on github) and CVE
> announcement (if any) now that part of the process is handled elsewhere).
>

+1

To my knowledge, the publishing of the site and overhaul of the new CVE
process are the things requiring updates.

-- 
Daniel Ruggeri

> The CVE announcement should be much easier, now that we have a "Send
> these Emails" on cveprocess.a.o. This should simplify part of the
> process where we were preparing some scripts to send the announcement
> emails.
>
> I've been lacking time for httpd since many weeks, but I should be
> able to RM next week if needed.
>
> CJ
>
>> Also: Anyone who has a showstopper to delay a release (even if not yet
>> proposed) please add it to 2.4.x STATUS so we can get things in order.
>>

APR 1.7.1 release?

[Rainer Jung]

Hi there,

any chance we find an RM for a APR 1.7.1 release? At least there was the 
fix for CVE-2021-35940 and CHANGES contains 15 more items (many of them 
platform specific or build improvements). Last release 1.7.0 was in 
April 2019.


For APR-util I don't know the current state and release needs for the 
1.6.x and 1.7.x branches. Last 1.6.x release was in October 2017, 1.7.x 
has never been released. CHANGES for 1.6.x only contains one 
apr_dbm_gdbm fix plus a minor libtool use improvement.


Apache httpd is planing to start a release cycle soon and it would be 
nice to have a clean APR 1.7.1 and maybe APR-util also.


Thanks and regards,

Rainer

Re: svn commit: r1892740 - in /httpd/httpd/trunk: changes-entries/ap_proxy_tunnel_run.txt modules/proxy/proxy_util.c

[Ruediger Pluem]

On 8/30/21 8:04 PM, yla...@apache.org wrote:
> Author: ylavic
> Date: Mon Aug 30 18:04:20 2021
> New Revision: 1892740
> 
> URL: http://svn.apache.org/viewvc?rev=1892740=rev
> Log:
> mod_proxy: Fix potential tunneling infinite loop and spurious timeout.
>PRs 65521 and 65519.
> 
> * modules/proxy/proxy_util.c(ap_proxy_tunnel_run):
>   Avoid an infinite loop by shutting down the connection for write when poll()
>   returns POLLHUP and read is already down.  PR 65521.
> 
> * modules/proxy/proxy_util.c(ap_proxy_tunnel_run):
>   When write completion is finished don't check for ap_filter_input_pending()
>   before proxy_tunnel_forward() to flush input data, this is a nonblocking 
> read
>   already which will do the same thing implicitely. ap_filter_input_pending()
>   is broken in 2.4.x without the whole pending data mechanism (not backported
>   yet), so let's align here.  PR 65519.
> 
> 
> Added:
> httpd/httpd/trunk/changes-entries/ap_proxy_tunnel_run.txt
> Modified:
> httpd/httpd/trunk/modules/proxy/proxy_util.c
> 

> Modified: httpd/httpd/trunk/modules/proxy/proxy_util.c
> URL: 
> http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/proxy/proxy_util.c?rev=1892740=1892739=1892740=diff
> ==
> --- httpd/httpd/trunk/modules/proxy/proxy_util.c (original)
> +++ httpd/httpd/trunk/modules/proxy/proxy_util.c Mon Aug 30 18:04:20 2021
> @@ -4890,12 +4890,16 @@ PROXY_DECLARE(int) ap_proxy_tunnel_run(p
>  return HTTP_INTERNAL_SERVER_ERROR;
>  }
>  
> -/* Write if we asked for POLLOUT, and got it or POLLERR
> - * alone (i.e. not with POLLIN|HUP). We want the output filters
> - * to know about the socket error if any, by failing the write.
> +/* We want to write if we asked for POLLOUT and got:
> + * - POLLOUT: the socket is ready for write;
> + * - !POLLIN: the socket is in error state (POLLERR) so we let
> + *   the user know by failing the write and log, OR the socket
> + *   is shutdown for read already (POLLHUP) so we have to
> + *   shutdown for write.
>   */
>  if ((tc->pfd->reqevents & APR_POLLOUT)
>  && ((pfd->rtnevents & APR_POLLOUT)
> +|| !(tc->pfd->reqevents & APR_POLLIN)

Why should we write if we requested POLLOUT did not get POLLOUT back, but did 
not request for POLLIN?

>  || !(pfd->rtnevents & (APR_POLLIN | APR_POLLHUP {
>  struct proxy_tunnel_conn *out = tc, *in = tc->other;
>  
> @@ -4944,12 +4948,25 @@ PROXY_DECLARE(int) ap_proxy_tunnel_run(p
>  return rc;
>  }
>  }
> +
> +/* Flush any pending input data now, we don't know when
> + * the next POLLIN will trigger and retaining data might
> + * deadlock the underlying protocol. We don't check for
> + * pending data first with ap_filter_input_pending() 
> since
> + * the read from proxy_tunnel_forward() is nonblocking
> + * anyway and returning OK if there's no data.
> + */
> +rc = proxy_tunnel_forward(tunnel, in);
> +if (rc != OK) {
> +return rc;
> +}

Don't we do all of this already a few lines above if 
ap_filter_input_pending(in->c) == OK?
Why doing it again?

Regards

Rüdiger

Re: release?

[Graham Leggett]

On 30 Aug 2021, at 12:35, ste...@eissing.org wrote:

> In what state is our release handling? Given someone holding my hand, could 
> I do it? Or is it better to look someone over the shoulder while he does it?

When I did it in the past, I walked through the commit emails of previous 
releases, and performed the same steps.

Regards,
Graham
—