You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ri...@apache.org on 2025/12/28 23:00:10 UTC
svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Author: rinrab
Date: Sun Dec 28 23:00:09 2025
New Revision: 1930949
Log:
Add OpenSSL backend for checksum computation.
After this change, every component that relies on checksuming would improve in
performance by a lot in thanks to OpenSSL optimised hash algorithms. My
benchmarks showed the following improvements:
- The benchmarking test was showing 0.16 GB/s raw speed with APR backend and
1.38 seconds GB/s with OpenSSL. All of those are SHA1. This is 8.62 times jump!
- Status of a working copy with a single file (with size of 370 MB) simply
touched was taking 1.94 seconds of real time to execute with APR backend and
0.30 seconds with OpenSSL (6.46 times improvement).
- The same test with a file of around 3 GB had a jump from 15.73 seconds to
2.23 seconds (7.05 times improvement).
- Checkout of the whole repository with those two files over file:// protocol
took 40 seconds with APR and 20 seconds with OpenSSL (2 times improvement).
Currenly, only CMake build system implements support for this feature. As far
as I checked, it should not at least break other build systems, but I didn't
implement support for them either.
This implementation relies on deprecated API of OpenSSL which (I think) is
objectively better than the approach they currenly consider recommended (which
is to use EVP interface).
1) it's just simpler
2) doesn't perform vtable calls
3) and OpenSSL uses it anyway in EVP
(personally, i don't get the reason why it was deprecated in the first place)
This is a completelly optional feature which is disabled by default. If one
doesn't want to use it, we wont force you to. There are many disadvantages of
loading such heavy libraries when we don't need all the stuff it gives us. This
optimisation comes with its own cost. But, our client already loads OpenSSL
indirectly through libserf so this is not an issue in some cases. Let's just
try it. Why not?
* CMakeLists.txt
(options): Add SVN_CHECKSUM_USE_OPENSSL.
(SVN_CHECKSUM_USE_OPENSSL): Check for option to decide whether to look for
the OpenSSL library and setup definitions or not.
(configsummary): Log value of SVN_CHECKSUM_USE_OPENSSL.
* build.conf
(libsvn_subr): Add dependency on openssl.
* subversion/libsvn_subr/checksum_apr.c
(): Put the whole file into an ifndef condition depending on
SVN_CHECKSUM_USE_OPENSSL.
* subversion/libsvn_subr/checksum_openssl.c
(svn_checksum__md5,
svn_checksum__md5_ctx_t,
svn_checksum__md5_ctx_create,
svn_checksum__md5_ctx_reset,
svn_checksum__md5_ctx_update,
svn_checksum__md5_ctx_final,
svn_checksum__sha1,
svn_checksum__sha1_ctx_t,
svn_checksum__sha1_ctx_create,
svn_checksum__sha1_ctx_reset,
svn_checksum__sha1_ctx_update,
svn_checksum__sha1_ctx_final): Implement through OpenSSL (under an ifdef).
Added:
subversion/trunk/subversion/libsvn_subr/checksum_openssl.c (contents, props changed)
Modified:
subversion/trunk/CMakeLists.txt
subversion/trunk/build.conf
subversion/trunk/subversion/libsvn_subr/checksum_apr.c
Modified: subversion/trunk/CMakeLists.txt
==============================================================================
--- subversion/trunk/CMakeLists.txt Sun Dec 28 20:22:21 2025 (r1930948)
+++ subversion/trunk/CMakeLists.txt Sun Dec 28 23:00:09 2025 (r1930949)
@@ -111,6 +111,7 @@ cmake_dependent_option(SVN_BUILD_SHARED_
option(SVN_DEBUG "Enables specific features for developer builds" OFF)
cmake_dependent_option(SVN_USE_WIN32_CRASHHANDLER "Enables WIN32 crash handler." ON "WIN32" OFF)
option(SVN_USE_DSO "Defined if svn should try to load DSOs" OFF)
+option(SVN_CHECKSUM_USE_OPENSSL "Defined if svn should use OpenSSL to compute checksums." OFF)
set(SVN_SOVERSION "0" CACHE STRING "Subversion library ABI version")
mark_as_advanced(SVN_SOVERSION)
@@ -383,6 +384,17 @@ if (SVN_ENABLE_RA_SERF)
endif()
endif()
+if (SVN_CHECKSUM_USE_OPENSSL)
+ find_package(OpenSSL REQUIRED)
+ add_library(external-openssl ALIAS OpenSSL::Crypto)
+ add_private_config_definition(
+ "Defined if svn should use OpenSSL to compute checksums."
+ "SVN_CHECKSUM_USE_OPENSSL" "1"
+ )
+else()
+ add_library(external-openssl INTERFACE)
+endif()
+
### Python
if(SVN_ENABLE_SWIG_PYTHON)
@@ -952,6 +964,7 @@ message(STATUS " Build shared librari
message(STATUS " Build shared FS Modues ........ : ${SVN_BUILD_SHARED_FS}")
message(STATUS " Build shared RA Modues ........ : ${SVN_BUILD_SHARED_RA}")
message(STATUS " Use pkg-config dependencies ... : ${SVN_USE_PKG_CONFIG}")
+message(STATUS " Use OpenSSL for checksum ...... : ${SVN_CHECKSUM_USE_OPENSSL}")
message(STATUS " FS modules:")
message(STATUS " Enable FSFS ................... : ${SVN_ENABLE_FS_FS}")
message(STATUS " Enable FSX .................... : ${SVN_ENABLE_FS_X}")
Modified: subversion/trunk/build.conf
==============================================================================
--- subversion/trunk/build.conf Sun Dec 28 20:22:21 2025 (r1930948)
+++ subversion/trunk/build.conf Sun Dec 28 23:00:09 2025 (r1930949)
@@ -394,7 +394,7 @@ install = fsmod-lib
path = subversion/libsvn_subr
sources = *.c lz4/*.c
libs = aprutil apriconv apr xml zlib apr_memcache
- sqlite magic intl lz4 utf8proc macos-plist macos-keychain
+ sqlite magic intl lz4 utf8proc macos-plist macos-keychain openssl
msvc-libs = kernel32.lib advapi32.lib shfolder.lib ole32.lib
crypt32.lib version.lib ws2_32.lib
msvc-export =
Modified: subversion/trunk/subversion/libsvn_subr/checksum_apr.c
==============================================================================
--- subversion/trunk/subversion/libsvn_subr/checksum_apr.c Sun Dec 28 20:22:21 2025 (r1930948)
+++ subversion/trunk/subversion/libsvn_subr/checksum_apr.c Sun Dec 28 23:00:09 2025 (r1930949)
@@ -22,6 +22,7 @@
*/
#include "svn_private_config.h"
+#ifndef SVN_CHECKSUM_USE_OPENSSL
#define APR_WANT_BYTEFUNC
@@ -130,3 +131,5 @@ svn_checksum__sha1_ctx_final(unsigned ch
return SVN_NO_ERROR;
}
+#endif /* SVN_CHECKSUM_USE_OPENSSL */
+
Added: subversion/trunk/subversion/libsvn_subr/checksum_openssl.c
==============================================================================
--- /dev/null 00:00:00 1970 (empty, because file is newly added)
+++ subversion/trunk/subversion/libsvn_subr/checksum_openssl.c Sun Dec 28 23:00:09 2025 (r1930949)
@@ -0,0 +1,159 @@
+/*
+ * checksum_openssl.c: OpenSSL backed checksums
+ *
+ * ====================================================================
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ * ====================================================================
+ */
+
+#include "svn_private_config.h"
+#ifdef SVN_CHECKSUM_USE_OPENSSL
+
+#define APR_WANT_BYTEFUNC
+
+#include <apr_md5.h>
+#include <apr_sha1.h>
+
+#include "svn_error.h"
+#include "checksum.h"
+
+/* There is an alternative way to compute checksums in OpenSSL which is to use
+ * their EVP interface. Here are the arguments why we are sticking with this
+ * one even though it's deprecated in OpenSSL v3.0:
+ *
+ * - EVP provides much more complicated interface.
+ *
+ * - We don't need the most of the features it gives us.
+ *
+ * - It might affect performance because there are vtable calls involved.
+ *
+ * - The default implementation used in EVP actually relies the exact same set
+ * of functions under the hood.
+ */
+
+#define OPENSSL_SUPPRESS_DEPRECATED
+#include <openssl/sha.h>
+#include <openssl/md5.h>
+
+
+/*** MD5 checksum ***/
+svn_error_t *
+svn_checksum__md5(unsigned char *digest,
+ const void *data,
+ apr_size_t len)
+{
+ MD5_CTX ctx;
+
+ MD5_Init(&ctx);
+ MD5_Update(&ctx, data, len);
+ MD5_Final(digest, &ctx);
+
+ return SVN_NO_ERROR;
+}
+
+svn_checksum__md5_ctx_t *
+svn_checksum__md5_ctx_create(apr_pool_t *pool)
+{
+ MD5_CTX *result = apr_palloc(pool, sizeof(*result));
+ MD5_Init(result);
+ return (svn_checksum__md5_ctx_t *)result;
+}
+
+svn_error_t *
+svn_checksum__md5_ctx_reset(svn_checksum__md5_ctx_t *ctx)
+{
+ MD5_CTX *md5_ctx = (MD5_CTX *)ctx;
+ memset(md5_ctx, 0, sizeof(*md5_ctx));
+ MD5_Init(md5_ctx);
+ return SVN_NO_ERROR;
+}
+
+svn_error_t *
+svn_checksum__md5_ctx_update(svn_checksum__md5_ctx_t *ctx,
+ const void *data,
+ apr_size_t len)
+{
+ MD5_CTX *md5_ctx = (MD5_CTX *)ctx;
+ MD5_Update(md5_ctx, data, len);
+ return SVN_NO_ERROR;
+}
+
+svn_error_t *
+svn_checksum__md5_ctx_final(unsigned char *digest,
+ const svn_checksum__md5_ctx_t *ctx)
+{
+ MD5_CTX *md5_ctx = (MD5_CTX *)ctx;
+ MD5_Final(digest, md5_ctx);
+ return SVN_NO_ERROR;
+}
+
+
+/*** SHA1 checksum ***/
+svn_error_t *
+svn_checksum__sha1(unsigned char *digest,
+ const void *data,
+ apr_size_t len)
+{
+ SHA_CTX ctx;
+
+ SHA1_Init(&ctx);
+ SHA1_Update(&ctx, data, len);
+ SHA1_Final(digest, &ctx);
+
+ return SVN_NO_ERROR;
+}
+
+svn_checksum__sha1_ctx_t *
+svn_checksum__sha1_ctx_create(apr_pool_t *pool)
+{
+ SHA_CTX *result = apr_palloc(pool, sizeof(*result));
+ SHA1_Init(result);
+ return (svn_checksum__sha1_ctx_t *)result;
+}
+
+svn_error_t *
+svn_checksum__sha1_ctx_reset(svn_checksum__sha1_ctx_t *ctx)
+{
+ SHA_CTX *sha_ctx = (SHA_CTX *)ctx;
+ memset(sha_ctx, 0, sizeof(*sha_ctx));
+ SHA1_Init(sha_ctx);
+ return SVN_NO_ERROR;
+}
+
+svn_error_t *
+svn_checksum__sha1_ctx_update(svn_checksum__sha1_ctx_t *ctx,
+ const void *data,
+ apr_size_t len)
+{
+ SHA_CTX *sha_ctx = (SHA_CTX *)ctx;
+ SHA1_Update(sha_ctx, data, len);
+ return SVN_NO_ERROR;
+}
+
+svn_error_t *
+svn_checksum__sha1_ctx_final(unsigned char *digest,
+ const svn_checksum__sha1_ctx_t *ctx)
+{
+
+ SHA_CTX *sha_ctx = (SHA_CTX *)ctx;
+ SHA1_Final(digest, sha_ctx);
+ return SVN_NO_ERROR;
+}
+
+#endif /* SVN_CHECKSUM_USE_OPENSSL */
+
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 30 dec. 2025 kl 18:58 skrev Branko Čibej <br...@apache.org>:
> On 30. 12. 25 18:36, Daniel Sahlberg wrote:
>
> Den tis 30 dec. 2025 kl 17:36 skrev Timofei Zhakov <ti...@chemodax.net>:
>
> ...
> - It's a great idea to "steal" optimized hash implementation, so we'd
>> get that performance boost without requiring any third-party
>> libraries. I think AWS-LC would be more suitable for this purpose
>> because it bundles pre-generated assembly sources whereas OpenSSL
>> needs perl for that.
>>
>
> I would not want to copy an existing implementation (including significant
> ASM code). That would open us up for a major investment in maintenance. I
> think we should keep the project simple by interfacing with external
> libraries that do this better, in line with the Unix philosophy of doing
> one thing and doing it well.
>
>
> Think of it as another SQLite amalgamation or utf8proc. It's not *that* much
> work once it's imported and spliced into the builds.
>
> (Which reminds me, someone should upgrade the built-in utf8proc before the
> next release. That, or we should make it a mandatory dependency, it's not a
> rare beast any more, even on Windows.)
>
I think you sort of made my point here: If we copy an external
implementation as we've done with utf8proc, we need to make sure it is kept
up-to-date.
I'm still not convinced that implementing support for a multitude of
different checksum providers in SVN makes sense. Of course, if APR decide
to take it under their wings, someone would have to maintain it there but
there is a benefit for all other APR-using projects. (Btw; I went ahead and
asked on the APR mailing list:
https://lists.apache.org/thread/bp5zyycdrlyszy83f0rxvjjv66s6bzts, no replys
yet).
Cheers,
Daniel
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Branko Čibej <br...@apache.org>.
On 30. 12. 25 18:36, Daniel Sahlberg wrote:
> Den tis 30 dec. 2025 kl 17:36 skrev Timofei Zhakov <ti...@chemodax.net>:
[...]
> Is there a significant downside to use OpenSSL? Ie, assuming that APR
> is build with OpenSSL support and using OpenSSL's checksumming
> algorithm. Will there be a significant additional time spent on
> loading the OpenSSL library if it is only used for calculating a checksum?
Process startup is not an issue here, especially on ELF platforms that
most likely have libcrypto already loaded in memory. It's slower on
Windows, but everything is anyway.
> I assume there are other project using APR behind the scenes.
As I said, there are potential issues if Serf, Subversion and APR all
use different versions of OpenSSL. This used to be a quite serious issue
on Windows back in the day, less so now when everything is a
side-by-side assembly, and it's even less of an issue with vcpkg and
similar available.
I think those issues are less now with OpenSSL 3, but can't be sure. In
most environments, with platforms maintainers taking care of package
versions, there should be no problems.
[...]
>
> - It's a great idea to "steal" optimized hash implementation, so we'd
> get that performance boost without requiring any third-party
> libraries. I think AWS-LC would be more suitable for this purpose
> because it bundles pre-generated assembly sources whereas OpenSSL
> needs perl for that.
>
>
> I would not want to copy an existing implementation (including
> significant ASM code). That would open us up for a major investment in
> maintenance. I think we should keep the project simple by interfacing
> with external libraries that do this better, in line with the Unix
> philosophy of doing one thing and doing it well.
Think of it as another SQLite amalgamation or utf8proc. It's not
/that/ much work once it's imported and spliced into the builds.
(Which reminds me, someone should upgrade the built-in utf8proc before
the next release. That, or we should make it a mandatory dependency,
it's not a rare beast any more, even on Windows.)
-- Brane
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Daniel Sahlberg <da...@gmail.com>.
Den tis 30 dec. 2025 kl 17:36 skrev Timofei Zhakov <ti...@chemodax.net>:
> I appreciate all suggestions and opinions mentioned. But let me
> clarify why I made those design choses a bit more.
>
> - Yes, it is faster because OpenSSL uses specific assembly
> instructions of modern CPUs.
>
Agree, if built with a specific ASM flag. (We also saw this in TortoiseSVN,
I think it was Evgeny who suggested it initially).
>
> - I believe that this optimization should *not* be done in APR
> (apr-util to be more specific). Most of its users don't want it to be
> crazy fast. They would most probably choose a more portable, simple,
> and lightweight implementation instead. Subversion, on the other hand,
> will generally work faster as checksumming improves.
>
A discussion of what APR and APR users want is probably out of scope /here/
but should go to dev@apr.
Agree that Subversion would benefit from a faster checksumming
implementation.
> - There is a public structure for checksum context data in APR so this
> might be problematic to adapt a different implementation.
>
Fair point - and this MAY be a dealbreaker for the APR project. But I'd
like to see it discussed on dev@apr first.
> - Httpd barely uses it and it's never critical to the overall
> performance part. I could find that only mod_lua and password
> authentication support uses SHA1 from APR. It's not an optimization
> whenever this code is called once a decade for like <20 bytes of data.
>
Is there a significant downside to use OpenSSL? Ie, assuming that APR is
build with OpenSSL support and using OpenSSL's checksumming algorithm. Will
there be a significant additional time spent on loading the OpenSSL library
if it is only used for calculating a checksum?
I assume there are other project using APR behind the scenes.
> - I discovered a much more convenient cryptography library (AWS-LC
> [1]). It's basically a fork of OpenSSL, but with simplified
> everything. We might make an interface for it as well.
>
Nice - but separate discussion.
>
> - It's a great idea to "steal" optimized hash implementation, so we'd
> get that performance boost without requiring any third-party
> libraries. I think AWS-LC would be more suitable for this purpose
> because it bundles pre-generated assembly sources whereas OpenSSL
> needs perl for that.
>
I would not want to copy an existing implementation (including significant
ASM code). That would open us up for a major investment in maintenance. I
think we should keep the project simple by interfacing with external
libraries that do this better, in line with the Unix philosophy of doing
one thing and doing it well.
Cheers,
Daniel
> Therefore, I suggest we move towards optimizing hashes in Subversion
> specifically. I don't like OpenSSL either, but it's a good enough
> direction to start.
>
> [1] https://github.com/aws/aws-lc
>
> --
> Timofei Zhakov
>
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Branko Čibej <br...@apache.org>.
On 30. 12. 25 17:36, Timofei Zhakov wrote:
> I appreciate all suggestions and opinions mentioned. But let me
> clarify why I made those design choses a bit more.
>
> - Yes, it is faster because OpenSSL uses specific assembly
> instructions of modern CPUs.
>
> - I believe that this optimization should *not* be done in APR
> (apr-util to be more specific). Most of its users don't want it to be
> crazy fast. They would most probably choose a more portable, simple,
> and lightweight implementation instead. Subversion, on the other hand,
> will generally work faster as checksumming improves.
>
> - There is a public structure for checksum context data in APR so this
> might be problematic to adapt a different implementation.
>
> - Httpd barely uses it and it's never critical to the overall
> performance part. I could find that only mod_lua and password
> authentication support uses SHA1 from APR. It's not an optimization
> whenever this code is called once a decade for like <20 bytes of data.
This is interesting info, thanks for digging into the sources.
> - I discovered a much more convenient cryptography library (AWS-LC
> [1]). It's basically a fork of OpenSSL, but with simplified
> everything. We might make an interface for it as well.
Note that code in AWS-LC code uses three different licenses, whereas
OpenSSL is now ALv2 all the way. With regards to licensing, it would be
far easier to lift code from current OpenSSL.
> - It's a great idea to "steal" optimized hash implementation, so we'd
> get that performance boost without requiring any third-party
> libraries. I think AWS-LC would be more suitable for this purpose
> because it bundles pre-generated assembly sources whereas OpenSSL
> needs perl for that.
That's not much of a hurdle; we could commit pre-generated assembly,
too, so not even developers would need Perl, only whoever imports [a new
version of] the hash code. We'd have to rename the public functions in
any case.
I can right now imagine the headache of adding assembly to the build
systems.
> Therefore, I suggest we move towards optimizing hashes in Subversion
> specifically. I don't like OpenSSL either, but it's a good enough
> direction to start.
There is nothing wrong with OpenSSL. Well, not much, lately...
About those deprecations: I suspect the old hash APIs are deprecated
because they're not equipped with all the fancy new auditing and error
reporting that the EVP API has. Not because the code itself will go
away, because OpenSSL surely can't work without those hash types. For
example, HMAC-SHA1 is still considered safe and is a widely used
signature algorithm.
-- Brane
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Timofei Zhakov <ti...@chemodax.net>.
I appreciate all suggestions and opinions mentioned. But let me
clarify why I made those design choses a bit more.
- Yes, it is faster because OpenSSL uses specific assembly
instructions of modern CPUs.
- I believe that this optimization should *not* be done in APR
(apr-util to be more specific). Most of its users don't want it to be
crazy fast. They would most probably choose a more portable, simple,
and lightweight implementation instead. Subversion, on the other hand,
will generally work faster as checksumming improves.
- There is a public structure for checksum context data in APR so this
might be problematic to adapt a different implementation.
- Httpd barely uses it and it's never critical to the overall
performance part. I could find that only mod_lua and password
authentication support uses SHA1 from APR. It's not an optimization
whenever this code is called once a decade for like <20 bytes of data.
- I discovered a much more convenient cryptography library (AWS-LC
[1]). It's basically a fork of OpenSSL, but with simplified
everything. We might make an interface for it as well.
- It's a great idea to "steal" optimized hash implementation, so we'd
get that performance boost without requiring any third-party
libraries. I think AWS-LC would be more suitable for this purpose
because it bundles pre-generated assembly sources whereas OpenSSL
needs perl for that.
Therefore, I suggest we move towards optimizing hashes in Subversion
specifically. I don't like OpenSSL either, but it's a good enough
direction to start.
[1] https://github.com/aws/aws-lc
--
Timofei Zhakov
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Branko Čibej <br...@apache.org>.
On 30. 12. 25 10:25, Branko Čibej wrote:
> On 30. 12. 25 08:58, Daniel Sahlberg wrote:
>> Den mån 29 dec. 2025 kl 18:55 skrev Branko Čibej <br...@apache.org>:
>>
>> Instead, why not report the results of your measurements to APR
>> and then, maybe, who knows, help to improve the performance of
>> APR's implementation? At the very least, every single
>> installation of Apache HTTPd that uses the improved APR will
>> become that tiny bit faster. Multiply by millions of installs and
>> it becomes clear that the impact would be far more positive than
>> just tweaking this in Subversion.
>>
>>
>> I think this is a very valid suggestion. The APR md5 implementation
>> is within the crypto module which, if I'm reading CMakeList.txt
>> correctly require OpenSSL. So the plumbing to use OpenSSL versions
>> should already be there.
>
> Note that while implemented in apr-util/crypto, the hash algorithms
> (md4, md5, sha1) do *not* depend on OpenSSL or any other crypto
> provider. You can configure apr-util --without-crypto and these
> functions will still be available. Making them dependent on a crypto
> provider would be considered a breaking change.
>
> Making them faster would likely involve using features of modern CPUs.
> OpenSSL has implementations in assembly for the most common platforms.
There's an interesting quirk here: OpenSSL is now licensed under the
Apache License, so APR could just "steal" those hash implementations.
But that's a discussion for another list.
The reason I pointed this out is that having a repeatable, public
benchmark that such as Tima just showed us could be a good argument for
doing something like that.
-- Brane
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Branko Čibej <br...@apache.org>.
On 30. 12. 25 08:58, Daniel Sahlberg wrote:
> Den mån 29 dec. 2025 kl 18:55 skrev Branko Čibej <br...@apache.org>:
>
> On 29. 12. 25 00:00, rinrab@apache.org wrote:
>
>> This implementation relies on deprecated API of OpenSSL which (I think) is
>> objectively better than the approach they currenly consider recommended (which
>> is to use EVP interface).
>
>
> Sorry, but this is a complete non-starter. Deprecated APIs tend to
> disappear from OpenSSL amazingly quickly since version 3.0. Which
> versions of OpenSSL did you test with? And what about LibreSSL,
> which is the default on, e.g., OpenBSD?
>
>
> If LibreSSL doesn't provide those functions, we'd just build without
> the SVN_CHECKSUM_USE_OPENSSL define? LibreSSL != OpenSSL after all...
LibreSSL == OpenSSL 1.x + security fixes, more or less[1]. It even
announces itself to as OpenSSL 2.x, which is why Serf, for example,
builds out of the box with LibreSSL without any patches. Although Serf
does already use OpenSSL's compatibility macros to deal with older APIs.
>
>
>
>> 1) it's just simpler
>> 2) doesn't perform vtable calls
>> 3) and OpenSSL uses it anyway in EVP
>>
>> (personally, i don't get the reason why it was deprecated in the first place)
>
>
> Doesn't matter if you get it or not. We shouldn't use deprecated
> APIs from our dependencies, and especially not from crypto stuff.
>
>
> I agree about not doing a new implementation based on deprecated APIs
> - unless those APIs are clearly not going away (some kind of
> "deprecated but not to be removed" promise from upstream). Otherwise
> we might end up in a situation where this suddenly doen't work and we
> have to scramble to get it working with the new API.
>
>
> There's also the added bit of fun when Serf and Subversion happen
> to link with different versions of OpenSSL ... or Apache and
> mod_dav_svn etc. link with different versions of OpenSSL. Although
> it's less likely these days to cause the sort of problems that
> were so "interesting" with OpenSSL 0.9 and 1.x, we should still
> avoid these situations if possible.
>
>
>> This is a completelly optional feature which is disabled by default. If one
>> doesn't want to use it, we wont force you to. There are many disadvantages of
>> loading such heavy libraries when we don't need all the stuff it gives us. This
>> optimisation comes with its own cost. But, our client already loads OpenSSL
>> indirectly through libserf so this is not an issue in some cases. Let's just
>> try it. Why not?
>
>
> Because some poor fool must maintain yet another optional
> bucketload of code, or let it bitrot.
>
> Instead, why not report the results of your measurements to APR
> and then, maybe, who knows, help to improve the performance of
> APR's implementation? At the very least, every single installation
> of Apache HTTPd that uses the improved APR will become that tiny
> bit faster. Multiply by millions of installs and it becomes clear
> that the impact would be far more positive than just tweaking this
> in Subversion.
>
>
> I think this is a very valid suggestion. The APR md5 implementation is
> within the crypto module which, if I'm reading CMakeList.txt correctly
> require OpenSSL. So the plumbing to use OpenSSL versions should
> already be there.
Note that while implemented in apr-util/crypto, the hash algorithms
(md4, md5, sha1) do *not* depend on OpenSSL or any other crypto
provider. You can configure apr-util --without-crypto and these
functions will still be available. Making them dependent on a crypto
provider would be considered a breaking change.
Making them faster would likely involve using features of modern CPUs.
OpenSSL has implementations in assembly for the most common platforms.
> @Timofei, what do you think about this?
>
>
> Adding even optional dependencies as a holiday gift to yourself, I
> mean, sure, I get it, but come on. :D
>
>
> I understand a joke but some of us have limited time outside of
> holiday/vacation time and anyone deciding to donate that time to the
> project should be met with respect and not being on the receiving end
> of a joke. Thanks.
Sorry. But you know, this is coming from some who's coding 12 hours a
day right now – maybe not Subversion or Serf, but certainly something
that's going to be open source. So yeah, if anything, the joke's on me.
[1] Plus a changed license and a holier-than-thou attitude from the
developers. Suffice it to say that it's not following the *real*
security fixes that are going into OpenSSL 3, so it's ever closer to
being as big a security risk as OpenSSL 1.x. But I digress.
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Daniel Sahlberg <da...@gmail.com>.
Den mån 29 dec. 2025 kl 18:55 skrev Branko Čibej <br...@apache.org>:
> On 29. 12. 25 00:00, rinrab@apache.org wrote:
>
> This implementation relies on deprecated API of OpenSSL which (I think) is
> objectively better than the approach they currenly consider recommended (which
> is to use EVP interface).
>
>
>
> Sorry, but this is a complete non-starter. Deprecated APIs tend to
> disappear from OpenSSL amazingly quickly since version 3.0. Which versions
> of OpenSSL did you test with? And what about LibreSSL, which is the default
> on, e.g., OpenBSD?
>
If LibreSSL doesn't provide those functions, we'd just build without the
SVN_CHECKSUM_USE_OPENSSL define? LibreSSL != OpenSSL after all...
>
> 1) it's just simpler
> 2) doesn't perform vtable calls
> 3) and OpenSSL uses it anyway in EVP
>
> (personally, i don't get the reason why it was deprecated in the first place)
>
>
>
> Doesn't matter if you get it or not. We shouldn't use deprecated APIs from
> our dependencies, and especially not from crypto stuff.
>
I agree about not doing a new implementation based on deprecated APIs -
unless those APIs are clearly not going away (some kind of "deprecated but
not to be removed" promise from upstream). Otherwise we might end up in a
situation where this suddenly doen't work and we have to scramble to get it
working with the new API.
> There's also the added bit of fun when Serf and Subversion happen to link
> with different versions of OpenSSL ... or Apache and mod_dav_svn etc. link
> with different versions of OpenSSL. Although it's less likely these days to
> cause the sort of problems that were so "interesting" with OpenSSL 0.9 and
> 1.x, we should still avoid these situations if possible.
>
>
> This is a completelly optional feature which is disabled by default. If one
> doesn't want to use it, we wont force you to. There are many disadvantages of
> loading such heavy libraries when we don't need all the stuff it gives us. This
> optimisation comes with its own cost. But, our client already loads OpenSSL
> indirectly through libserf so this is not an issue in some cases. Let's just
> try it. Why not?
>
>
>
> Because some poor fool must maintain yet another optional bucketload of
> code, or let it bitrot.
>
> Instead, why not report the results of your measurements to APR and then,
> maybe, who knows, help to improve the performance of APR's implementation?
> At the very least, every single installation of Apache HTTPd that uses the
> improved APR will become that tiny bit faster. Multiply by millions of
> installs and it becomes clear that the impact would be far more positive
> than just tweaking this in Subversion.
>
I think this is a very valid suggestion. The APR md5 implementation is
within the crypto module which, if I'm reading CMakeList.txt correctly
require OpenSSL. So the plumbing to use OpenSSL versions should already be
there.
@Timofei, what do you think about this?
>
> Adding even optional dependencies as a holiday gift to yourself, I mean,
> sure, I get it, but come on. :D
>
I understand a joke but some of us have limited time outside of
holiday/vacation time and anyone deciding to donate that time to the
project should be met with respect and not being on the receiving end of a
joke. Thanks.
Cheers,
Daniel
>
> -- Brane
>
>
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Branko Čibej <br...@apache.org>.
$#&!@#$*&^! Thunderbird not honouring Reply-To...
On 29. 12. 25 18:55, Branko Čibej wrote:
> On 29. 12. 25 00:00, rinrab@apache.org wrote:
>
>> This implementation relies on deprecated API of OpenSSL which (I think) is
>> objectively better than the approach they currenly consider recommended (which
>> is to use EVP interface).
>
>
> Sorry, but this is a complete non-starter. Deprecated APIs tend to
> disappear from OpenSSL amazingly quickly since version 3.0. Which
> versions of OpenSSL did you test with? And what about LibreSSL, which
> is the default on, e.g., OpenBSD?
>
>
>> 1) it's just simpler
>> 2) doesn't perform vtable calls
>> 3) and OpenSSL uses it anyway in EVP
>>
>> (personally, i don't get the reason why it was deprecated in the first place)
>
>
> Doesn't matter if you get it or not. We shouldn't use deprecated APIs
> from our dependencies, and especially not from crypto stuff.
>
> There's also the added bit of fun when Serf and Subversion happen to
> link with different versions of OpenSSL ... or Apache and mod_dav_svn
> etc. link with different versions of OpenSSL. Although it's less
> likely these days to cause the sort of problems that were so
> "interesting" with OpenSSL 0.9 and 1.x, we should still avoid these
> situations if possible.
>
>
>> This is a completelly optional feature which is disabled by default. If one
>> doesn't want to use it, we wont force you to. There are many disadvantages of
>> loading such heavy libraries when we don't need all the stuff it gives us. This
>> optimisation comes with its own cost. But, our client already loads OpenSSL
>> indirectly through libserf so this is not an issue in some cases. Let's just
>> try it. Why not?
>
>
> Because some poor fool must maintain yet another optional bucketload
> of code, or let it bitrot.
>
> Instead, why not report the results of your measurements to APR and
> then, maybe, who knows, help to improve the performance of APR's
> implementation? At the very least, every single installation of Apache
> HTTPd that uses the improved APR will become that tiny bit faster.
> Multiply by millions of installs and it becomes clear that the impact
> would be far more positive than just tweaking this in Subversion.
>
> Adding even optional dependencies as a holiday gift to yourself, I
> mean, sure, I get it, but come on. :D
>
> -- Brane
>
Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr
Posted by Branko Čibej <br...@apache.org>.
On 29. 12. 25 00:00, rinrab@apache.org wrote:
> This implementation relies on deprecated API of OpenSSL which (I think) is
> objectively better than the approach they currenly consider recommended (which
> is to use EVP interface).
Sorry, but this is a complete non-starter. Deprecated APIs tend to
disappear from OpenSSL amazingly quickly since version 3.0. Which
versions of OpenSSL did you test with? And what about LibreSSL, which is
the default on, e.g., OpenBSD?
> 1) it's just simpler
> 2) doesn't perform vtable calls
> 3) and OpenSSL uses it anyway in EVP
>
> (personally, i don't get the reason why it was deprecated in the first place)
Doesn't matter if you get it or not. We shouldn't use deprecated APIs
from our dependencies, and especially not from crypto stuff.
There's also the added bit of fun when Serf and Subversion happen to
link with different versions of OpenSSL ... or Apache and mod_dav_svn
etc. link with different versions of OpenSSL. Although it's less likely
these days to cause the sort of problems that were so "interesting" with
OpenSSL 0.9 and 1.x, we should still avoid these situations if possible.
> This is a completelly optional feature which is disabled by default. If one
> doesn't want to use it, we wont force you to. There are many disadvantages of
> loading such heavy libraries when we don't need all the stuff it gives us. This
> optimisation comes with its own cost. But, our client already loads OpenSSL
> indirectly through libserf so this is not an issue in some cases. Let's just
> try it. Why not?
Because some poor fool must maintain yet another optional bucketload of
code, or let it bitrot.
Instead, why not report the results of your measurements to APR and
then, maybe, who knows, help to improve the performance of APR's
implementation? At the very least, every single installation of Apache
HTTPd that uses the improved APR will become that tiny bit faster.
Multiply by millions of installs and it becomes clear that the impact
would be far more positive than just tweaking this in Subversion.
Adding even optional dependencies as a holiday gift to yourself, I mean,
sure, I get it, but come on. :D
-- Brane