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

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

-- 
John Baldwin