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
