On 30. 12. 25 08:58, Daniel Sahlberg wrote:
Den mån 29 dec. 2025 kl 18:55 skrev Branko Čibej <[email protected]>:
On 29. 12. 25 00:00, [email protected] 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.
