Comment 1 Lev A. Serebryakov 2015-08-21 12:07:48 UTC

Do you have www/neon built with OPENSSL?

Comment 2 Lev A. Serebryakov 2015-08-21 12:10:57 UTC

Oh, sorry, it is not neon, but sef now.

This error message could be issued only due to serf (www/serf) failure… Interesting.

Right, and www/serf has no OPENSSL option. For reference, my serf was built like so:

# pkg query '%Ok = %Ov' serf
DOCS = on
GSSAPI = off

But I don't see how this could be related to any ports compile-time options since the subversion tarball downloaded from the Apache project page correctly functions with the 'servers' file I listed in the initial bug report. Additionally, the libraries linked (as shown by ldd) are the same between the ports-built copy and the one I built directly from Apache's sources.

Comment 4 Lev A. Serebryakov 2015-08-21 12:56:01 UTC

Yep, SERF has OpenSSL support unconditionally.

But this error message (E125009) is used only if one of two SERF calls:

serf_ssl_load_cert_file()
serf_ssl_trust_cert()

return error.

I'm investigating what is wrong with svn from ports right now…

Comment 5 Lev A. Serebryakov 2015-08-21 13:08:56 UTC

(for the record)

serf_ssl_trust_cert() fails (subversion/libsvn_ra_serf/util.c:523).

I can not understand — why?!

Comment 6 Lev A. Serebryakov 2015-08-21 13:53:13 UTC

Could you please provide full "configure" and "gmake" command lines which you use to build working subversion "by hands"?

I pulled my manual configure options from the Poudriere output for the port, resulting in the following build sequence (and obviously my own prefix to avoid conflicting with ports.)

My build:

./configure --without-swig  --with-sqlite=/usr/local  --with-expat=/usr/local/include:/usr/local/lib:expat --without-berkeley-db --disable-nls --without-sasl --with-serf=/usr/local --with-apr=/usr/local/bin/apr-1-config --with-apr-util=/usr/local/bin/apu-1-config --without-gnome-keyring  --without-kwallet  --with-apxs=no --without-berkeley-db --prefix=/home/josh/apps/subversion-1.8.14

make -j2
make install

Here's what Poudriere had to say about the 1.8.14 build:

---Begin OPTIONS List---
===> The following configuration options are available for subversion-1.8.14_1:
     BDB=off: Berkeley DB support
     DOCS=on: Build and/or install documentation
     FREEBSD_TEMPLATE=on: FreeBSD Project log template
     MAINTAINER_DEBUG=off: Build debug version
     NLS=off: Native Language Support
     P4_STYLE_MARKERS=on: Perforce-style conflict markers
     SASL=off: SASL authentication support
     SERF=on: WebDAV/Delta-V (HTTP/HTTPS) repo access module
     STATIC=off: Build static version (no shared libs)
     SVNSERVE_WRAPPER=off: Enable svnserve wrapper (umask setter)
     TEST=off: Run subversion test suite
     TOOLS=on: Install several tools
===> Use 'make config' to modify these settings
---End OPTIONS List---

--CONFIGURE_ARGS--
--without-swig  --with-sqlite=/usr/local  --with-expat=/usr/local/include:/usr/local/lib:expat --without-berkeley-db --disable-nls --without-sasl --with-serf --with-apr=/usr/local/bin/apr-1-config --with-apr-util=/usr/local/bin/apu-1-config --without-gnome-keyring  --without-kwallet  --with-apxs=no --without-berkeley-db --prefix=/usr/local ${_LATE_CONFIGURE_ARGS}
--End CONFIGURE_ARGS--

Comment 8 Lev A. Serebryakov 2015-08-21 15:41:31 UTC

It is mysterious! Looks like I need OpenSSL guru…

Comment 9 Lev A. Serebryakov 2015-08-21 15:41:58 UTC

BTW, svn *without* port patches works, am I right?

Apologies for the delay in following-up, but I had limited luck trying to remove all the port-specific modifications to the upstream code as they seem to be scattered in a few places in the Makefile.

I tried removing all the files in the port dir matching a name of ./files/patch-*, and the port failed to built as the plist file is expecting the programs like 'diff' to be renamed 'svndiff' per the build-outputs.mk patch.

I did have build-success when I left in the two files: patch-Makefile.in & patch-build-outputs.mk. HOWEVER, the resulting port was still broken in the same way the standard port was in that it failed to parse the X.509 CA cert from the global SVN configuration, as in the original bug report.

I notice there are a half-dozen "extra" patch files that appear to get conditionally applied due to various tunable options. Is one of these perhaps responsible? Is there a patch or modification I can try to see if further removing port-tweaks to the upstream sources is ultimately the cause of this issue?

There are also some inline replacements made (via REINPLACE_CMD), although these appear limited to path/shebang corrections and presumably unrelated to the certificate parsing problem.

I've tracked down the cause of this bug to the change in ca_root_nss package which now provides the /etc/ssl/cert.pem symlink to the Mozilla CA root-cert X.509 bundle.

The issue here is that Subversion (or the OpenSSL calls it relies on) chokes when a duplicate CA is added to the list of trusted roots. When this happens, the high-level action of "loading" the file specified by ssl-authority-files in the system or user-specific 'servers' file will fail.

The failure mode is identical to the case where the file doesn't actually exist, leaving the user with little clue about the root cause. At this point it's a Subversion/OpenSSL issue, not specific to FreeBSD.

If any other users run into this bug, the solution is to verify the root-CA for the server in question really is in the bundle referenced by cert.pem, then remove the configuration directive pointing to the same cert. Optionally removing the cert.pem symlink (or the port option creating it) restores the old behavior of the ca_root_nss port and the packages that will use this file by default.

Unless there was more to do, I think this bug can be closed out.

Comment 12 Lev A. Serebryakov 2016-03-19 13:56:53 UTC

If it is a bug, it is a bug in OpenSSL, not in apr/subversion.