Re: [PR] Link pthread library when using OpenSSL on Linux [openoffice]
DamjanJovanovic commented on PR #206: URL: https://github.com/apache/openoffice/pull/206#issuecomment-2027757168 Oh right, on Linux pthreads is in a separate library, and internal OpenSSL is linked statically, so the binary linking to OpenSSL has to link to pthreads as well. Forgot about that case. Sorry. Your patch looks good. Thank you. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: [PR] Possible fix for issue 60859 [openoffice]
ardovm commented on PR #200: URL: https://github.com/apache/openoffice/pull/200#issuecomment-2027708940 The logic had to be a little more complex than that. If there is a visible slides after the selection, then it has to be selected. Otherwise, we have to search for a visible slide backward. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Next blog post
Dear All, trunk has seen quite a lot of work recently, and because it's trunk, it is proceeding in a somewhat hidden way. Due to the fact that the last post on our blog is already 3 months old, I suggest we make a new post to just tell what it is going on behind the scenes. The most relevant things that we I could list are the following: - OpenSSL upgrade (this is related to security, encryption and digital signatures); - implementation of OOXML encryption (this helps compatibility with other office suites); - fix of compilation errors under the latest Ubuntu (this helps contributors build and test AOO on their systems) - allow pasting of vector graphics (this helps making prettier documents) - various fixes in documentation, help files and interface (this makes the overall user experience smoother) - various spelling fixes in the source code and documentation (this helps developers) - various code fixes and cleanups (this helps developers focus on interesting things) Some other commits look ``important'' but I cannot explain them and need some help: * 00ab6c3f8bc46b7dee5058d1206cc64de18809de Removing all High Contrast icons from 'Classic' icon set. I prepared a draft on our wiki at [1], so anyone can contribute to the text. I am no native English speaker, nor marketing expert... feel free to correct it! Can we sort out something in this weekend? It would be great to publish, say, on April 2nd! Comments and suggestions welcome. Best regards. References: 1: https://cwiki.apache.org/confluence/x/1gniEQ -- Arrigo - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: OpenSSL upgraded to 3.0.13
Hi Damjan, Am 29.03.24 um 10:33 schrieb Damjan Jovanovic: Hi I've now pushed commit 4c5b548fb6ece87dd30bbf720aca0d994a749167 into trunk, upgrading our OpenSSL version from 1.0.2u to 3.0.13. Great! I am just doing a build on Windows. Regards, Matthias Some issues to consider: - PLATFORMS - It works on FreeBSD 14, both with system OpenSSL linked dynamically and internal OpenSSL linked statically. Linux hasn't been tested but is so similar to FreeBSD that it really should work. It works on Windows, with the following changes: - OpenSSL requires Perl to build, but doesn't like Cygwin's Perl. Previously, OpenSSL 1.0.2u was patched to use Cygwin's Perl, but OpenSSL 3 completely changed the build system, and I couldn't port the old patches. Now note how traditionally our build tools (eg. make, Apache Ant, awk, sed, etc.) were all installed prior to building OpenOffice, detected by ./configure, and then used during the build. I've done something different: during ./bootstrap it will now download the Win32 Strawberry Perl portable binaries as a dependency, and while building OpenSSL, it will unzip these and temporarily use them as the Perl for building OpenSSL. This works, and should reliably continue to work, but is a bit unusual, uses close to 800 MB extra disk space, and cannot use a system-wide Strawberry Perl instead of the portable binaries, so it is something we may want to change going forward. On the plus side, this new approach neither requires any additional options to ./configure, nor babysitting any more build dependencies, nor dragging around long patches to change OpenSSL to use Cygwin's Perl. If anybody objects, speak up. - Some defines were missing from MSVC's header files, for the ancient version of the MSVC compiler we use, so I had to add them as command line parameters to the compiler instead, eg. "-DINT64_MAX=9223372036854775807i64". - OpenSSL normally requires fairly recent versions of Windows, but also supports the more minimal Windows CE, and so has fallback paths that can be used for older versions of Windows. I've configured it to target Windows 95 and NT 4.0, and added a small number of patches that fix the build issues, mostly by using the Windows CE fallback code. - NASM is handled better: before, when NASM was already in the $PATH instead of --with-nasm-path being passed to ./configure, building openssl would break. It now works. - Python needed a lot of patching to use OpenSSL 3, and the Win64 build of python is probably broken and will need further work. - It takes really long to build. We could disable unit tests to speed it up (by passing "no-tests" to Configure), but I am not sure I like skipping tests. We should be testing more, not less. macOS? Who knows. It looks like on macOS, our main/openssl module links statically, and doesn't apply any patches, so it might already work. - LICENSING - Licensing has changed, as OpenSSL 3 is under the Apache Software License v2 like ourselves, and our LICENSE and NOTICE files have been greatly simplified. - CODE CHANGES - Remarkably, no changes to our C/C++ code were required. Some code changes were required in the past, eg. f884850fece86ece56c7194bb1e746641f77c0a0 to deal with EVP_CIPHER_CTX_init() -> EVP_CIPHER_CTX_new() between OpenSSL 1.0.x and 1.1.x. However, nothing needed changing between 1.1.x and 3.0.13, OpenSSL was sufficiently backward compatible. -- OTHER BRANCHES -- While those 1.0.x -> 1.1.x code changes are in trunk, they may be absent from other branches, so cherry picking this commit to other branches may require more commits to be cherry picked. - FUTURE - OpenSSL 3.0.x is the LTS release series, and will be supported until 2026-09-07. Regards Damjan smime.p7s Description: Kryptografische S/MIME-Signatur
Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!
Hi Damjan, Am 29.03.24 um 11:17 schrieb Damjan Jovanovic: On Sun, Mar 17, 2024 at 5:46 PM Matthias Seidel wrote: Hi Dave, Am 17.03.24 um 18:01 schrieb Dave Fisher: 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, We need to update a lot of things, including openSSL and MSVC... But we should first try to get a working build system for AOO42X, so we are able to do a release after all these years. My PRs are on hold until then. Even my work on the Help files has stopped because of the old SDF files. What is wrong with the build system for AOO42X? "Build system" may be the wrong phrase... "Release system" may be better. We are able to build en-US, but every commit that changes strings or adds new ones makes the translated versions more and more unusable due to the outdated SDF files. For AOO41X I began to patch the SDF files, but that is error prone and definitely not usable for AOO42X. Pootle seems to be unmaintained and we still need to find a working alternative. Regards, Matthias Regards Damjan smime.p7s Description: Kryptografische S/MIME-Signatur
Re: MS Office 2010+ "Agile" encrypted OOXML documents are working now!
On Sun, Mar 17, 2024 at 5:46 PM Matthias Seidel wrote: > Hi Dave, > > Am 17.03.24 um 18:01 schrieb Dave Fisher: > > 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, > > We need to update a lot of things, including openSSL and MSVC... > > But we should first try to get a working build system for AOO42X, so we > are able to do a release after all these years. > > My PRs are on hold until then. Even my work on the Help files has > stopped because of the old SDF files. > > What is wrong with the build system for AOO42X? Regards Damjan
OpenSSL upgraded to 3.0.13
Hi I've now pushed commit 4c5b548fb6ece87dd30bbf720aca0d994a749167 into trunk, upgrading our OpenSSL version from 1.0.2u to 3.0.13. Some issues to consider: - PLATFORMS - It works on FreeBSD 14, both with system OpenSSL linked dynamically and internal OpenSSL linked statically. Linux hasn't been tested but is so similar to FreeBSD that it really should work. It works on Windows, with the following changes: - OpenSSL requires Perl to build, but doesn't like Cygwin's Perl. Previously, OpenSSL 1.0.2u was patched to use Cygwin's Perl, but OpenSSL 3 completely changed the build system, and I couldn't port the old patches. Now note how traditionally our build tools (eg. make, Apache Ant, awk, sed, etc.) were all installed prior to building OpenOffice, detected by ./configure, and then used during the build. I've done something different: during ./bootstrap it will now download the Win32 Strawberry Perl portable binaries as a dependency, and while building OpenSSL, it will unzip these and temporarily use them as the Perl for building OpenSSL. This works, and should reliably continue to work, but is a bit unusual, uses close to 800 MB extra disk space, and cannot use a system-wide Strawberry Perl instead of the portable binaries, so it is something we may want to change going forward. On the plus side, this new approach neither requires any additional options to ./configure, nor babysitting any more build dependencies, nor dragging around long patches to change OpenSSL to use Cygwin's Perl. If anybody objects, speak up. - Some defines were missing from MSVC's header files, for the ancient version of the MSVC compiler we use, so I had to add them as command line parameters to the compiler instead, eg. "-DINT64_MAX=9223372036854775807i64". - OpenSSL normally requires fairly recent versions of Windows, but also supports the more minimal Windows CE, and so has fallback paths that can be used for older versions of Windows. I've configured it to target Windows 95 and NT 4.0, and added a small number of patches that fix the build issues, mostly by using the Windows CE fallback code. - NASM is handled better: before, when NASM was already in the $PATH instead of --with-nasm-path being passed to ./configure, building openssl would break. It now works. - Python needed a lot of patching to use OpenSSL 3, and the Win64 build of python is probably broken and will need further work. - It takes really long to build. We could disable unit tests to speed it up (by passing "no-tests" to Configure), but I am not sure I like skipping tests. We should be testing more, not less. macOS? Who knows. It looks like on macOS, our main/openssl module links statically, and doesn't apply any patches, so it might already work. - LICENSING - Licensing has changed, as OpenSSL 3 is under the Apache Software License v2 like ourselves, and our LICENSE and NOTICE files have been greatly simplified. - CODE CHANGES - Remarkably, no changes to our C/C++ code were required. Some code changes were required in the past, eg. f884850fece86ece56c7194bb1e746641f77c0a0 to deal with EVP_CIPHER_CTX_init() -> EVP_CIPHER_CTX_new() between OpenSSL 1.0.x and 1.1.x. However, nothing needed changing between 1.1.x and 3.0.13, OpenSSL was sufficiently backward compatible. -- OTHER BRANCHES -- While those 1.0.x -> 1.1.x code changes are in trunk, they may be absent from other branches, so cherry picking this commit to other branches may require more commits to be cherry picked. - FUTURE - OpenSSL 3.0.x is the LTS release series, and will be supported until 2026-09-07. Regards Damjan
