Re: svn commit: r1930949 - in subversion/trunk: . subversion/libsvn_subr

Branko Čibej <[email protected]>
Newsgroups gmane.comp.version-control.subversion.svn
Organization The Apache Software Foundation
Message-ID <[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?


> 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.