On 2/11/21 9:59 AM, Hartmann, O. wrote:
On Wed, 10 Feb 2021 07:21:20 +0100
"Hartmann, O." <o.hartm...@walstatt.org> wrote:
On Tue, 9 Feb 2021 15:15:38 -0800
John Baldwin <j...@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@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 <rmack...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
