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... > > 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 > >
