(n244517-f17fc5439f5) svn stuck forever in /usr/ports?
John Baldwin
jhb at FreeBSD.org
Fri Feb 26 00:22:04 UTC 2021
On 2/11/21 9:59 AM, Hartmann, O. wrote:
> 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@ 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)
>>> @@ -0,0 +1,11 @@
>>> +--- 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
>>> +@@ -542,7 +542,7 @@ 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
I finally reproduced this today and was able to at least get a valid response back
from the server using openssl s_client as the client with a larger version of this
patch.
You can find the full patch at https://reviews.freebsd.org/D28932
--
John Baldwin
More information about the freebsd-current
mailing list