Re: (n244517-f17fc5439f5) svn stuck forever in /usr/ports?

On Wed, 10 Feb 2021 07:21:20 +0100
"Hartmann, O." <o.hartmann_at_walstatt.org> wrote:

> On Tue, 9 Feb 2021 15:15:38 -0800
> John Baldwin <jhb_at_FreeBSD.org> wrote:
> 
> > On 2/9/21 2:16 PM, Hartmann, O. wrote:  
> > > On Wed, 3 Feb 2021 17:34:24 +0100
> > > Guido Falsi via freebsd-current <freebsd-current_at_freebsd.org> wrote:
> > >     
> > >> On 03/02/21 17:02, John Baldwin wrote:    
> > >>> On 2/2/21 10:16 PM, Hartmann, O. wrote:    
> > >>>> On Mon, 1 Feb 2021 03:24:45 +0000
> > >>>> Rick Macklem <rmacklem_at_uoguelph.ca> wrote:
> > >>>>       
> > >>>>> Rick Macklem wrote:    
> > >>>>>> Guido Falsi wrote:
> > >>>>>> [good stuff snipped]    
> > >>>>>>> Performed a full bisect. Tracked it down to commit aa906e2a4957,
> > >>>>>>> adding
> > >>>>>>> KTLS support to embedded OpenSSL.
> > >>>>>>>
> > >>>>>>> I filed a bug report about this:
> > >>>>>>>
> > >>>>>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253135
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> Apart from switching to svn:// scheme, another workaround is to build
> > >>>>>>> base using WITHOUT_OPENSSL_KTLS.    
> > >>>>>> Just fyi, when I tested the daemons I have for nfs-over-tls (which
> > >>>>>> use ktls),
> > >>>>>> they acted like things were ok (no handshake problems), but the data
> > >>>>>> ended up on the wire unencrypted (nfs-over-tls doesn't do a
> > >>>>>> SSL_write(),
> > >>>>>> so it depends on ktls to do the encryption).
> > >>>>>>
> > >>>>>> Since these daemons work fine with openssl3 in
> > >>>>>> ports/security/openssl-devel,
> > >>>>>> I suspect the ktls backport is not quite right. I've sent jhb_at_ email.    
> > >>>>> I was wrong on the above. I did a full buildworld/installworld and
> > >>>>> the daemons
> > >>>>> now seem to work with the openssl in head/main.
> > >>>>>
> > >>>>> Btw, did anyone try rebuilding svn from sources after doing
> > >>>>> the system upgrade?
> > >>>>> (The openssl library calls and .h files definitely changed.)    
> > >>>>
> > >>>> Yes, I did, on all boxes and its a pain in the a..., we had to rebuild
> > >>>> EVERY port (at
> > >>>> least, I did, to avoid further problem). Yesterday, on of our fastes
> > >>>> boxes got ready and
> > >>>> even with a full rebuild of the system AND a full rebuild of the ports
> > >>>> (no poudriere,
> > >>>> traditional way via make), the Apache 2.4 webservice doesn't work, and
> > >>>> so does subversion
> > >>>> not (Firefox reports problems with SSL handshake, subversion is
> > >>>> stuck/frozen forever).
> > >>>> I will run today another full world build today, hopefully finishing
> > >>>> on friday (portmaster
> > >>>> -dfR doesn't get everything in line on some ports, I assume).
> > >>>>
> > >>>> oh    
> > >>>
> > >>> I tracked the subversion hang down to a bug in serf (an Apache library
> > >>> used by
> > >>> subversion).  It would also affect any other software using serf.  The
> > >>> serf in
> > >>> ports will also have to be patched.
> > >>>        
> > >>
> > >> I submitted your patch as a bug report to the serf port:
> > >>
> > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253214
> > >>    
> > > 
> > > What is the status of this bug?
> > > As PR 253214 might suggest, the patch to www/serf has been commited. We still face a
> > > problem with FreeBSD CURRENT-14 based systems running Apache24:
> > > 
> > > FreeBSD 14.0-CURRENT #4 main-n244672-866c8b8d5dd: Mon Feb  8 08:38:59 CET 2021 amd64
> > > 
> > > /usr/ports is at Revision: 564736.
> > > 
> > > www/apache24, www/serf have been rebuilt using "portmaster -f www/apache24
> > > www/serf".
> > > 
> > > Restarting Apache 2.4 still fails on any access with SSL enabled, firefox reports:
> > > 
> > > SSL_ERROR_HANDSHAKE_UNEXPECTED_ALERT    
> > 
> > This is the first report I've had after the serf update.
> > 
> > Here's an untested patch that is similar to the serf bug.  You would
> > apply this in the www/apache24 port.
> > 
> > Index: files/patch-modules_ssl_ssl__engine__io.c
> > ===================================================================
> > --- files/patch-modules_ssl_ssl__engine__io.c   (nonexistent)
> > +++ files/patch-modules_ssl_ssl__engine__io.c   (working copy)
> > _at__at_ -0,0 +1,11 _at__at_
> > +--- modules/ssl/ssl_engine_io.c.orig   2021-02-09 15:09:39.362123000 -0800
> > ++++ modules/ssl/ssl_engine_io.c        2021-02-09 15:12:13.596690000 -0800
> > +_at__at_ -542,7 +542,7 _at__at_ static int bio_filter_in_gets(BIO *bio, char *buf, int
> > +
> > + static long bio_filter_in_ctrl(BIO *bio, int cmd, long num, void *ptr)
> > + {
> > +-    return -1;
> > ++    return 0;
> > + }
> > +
> > + #if MODSSL_USE_OPENSSL_PRE_1_1_API
> >   
> 
> Thank you very much for investigating and the patch.
> 
> I haven't got the chance to apply the patch yet, I'll do within the next two hours. For
> the record: I filed a PR on this specific problem in Apache 2.4, please see here:
> 
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253394
> 
> Kind regards,
> 
> O. Hartmann


I tried the patch, it doesn't work.
Assuming that it is sufficient to recompile from scratch/clean tree the whole OS and then
recompile every port required by www/apach24, applying then the patch, I tried to connect
to pages served by the 14-CURRENT server running the pacthed Apache 2.4 (ports tree at
the most recent state at that time), I still get the error described above.

Kind regards,

oh