Hi Damjan, +1 for upgrading OpenSSL, at least for trunk/AOO42X.
That said, I can not estimate if this is an "easy" fix... Regards, Matthias Am 17.03.24 um 18:42 schrieb Damjan Jovanovic:
Hi Is there some reason we are still using such an old version of OpenSSL? >From what I see, these are the modules that depend on OpenSSL: $ grep -l openssl */prj/build.lst curl/prj/build.lst oox/prj/build.lst openssl/prj/build.lst python/prj/build.lst redland/prj/build.lst ucb/prj/build.lst curl: is a heavy user of OpenSSL and really should support new versions. oox: only used by the Standard/Agile encryption, which I successfully tested against OpenSSL 3 recently. python: compiles and links against OpenSSL 3. redland: unknown ucb: used only by the WebDAV content provider, which I added it to, and compiles and links against OpenSSL 3, probably already works too. It seems like an upgrade will be easy? Regards Damjan On Sun, Mar 17, 2024 at 5:03 PM Dave Fisher <w...@apache.org> wrote:Hi Damjan, I know it “opens a big can of worms” and is another issue, but upgrading to a newer OpenSSL for Trunk and maybe 4.2 would be a very good thing, Best, DaveOn Mar 17, 2024, at 4:23 AM, Damjan Jovanovic <dam...@apache.org> wrote: Also that ancient OpenSSL version we use internally, 1.0.x, uses EVP_MD_CTX_create()/destroy() instead of EVP_MD_CTX_new()/free(). Finally some template function was unhappy about parameter type ambiguity (even though superior compilers like Clang are perfectly happy), and I had toaddcasts.
smime.p7s
Description: Kryptografische S/MIME-Signatur
