Apache OpenOffice (AOO) Bugzilla – Issue 127789
update error(s) including program and extension
Last modified: 2022-10-28 12:54:20 UTC
Both update and extension~manager "Server error message:" are blank. Would be nice if there was an accurate and meaningful message so I can attempt to resolve the issue. It seems to happen every time so it is very easily reproducible. I installed the current version of LibreOffice [Version: 5.4.7.2 (x64)}] and both program update and extension update work fine (updates are shown when available). Thanks, Tracey OO4.1.5 Updates: Checking for an update failed. : Error reading data from the Internet. : Server error message: . Ext Manager: Error reading data from the Internet. : Server error message: .
(In reply to Tracey from comment #0) > Both update and extension~manager "Server error message:" are blank. > Would be nice if there was an accurate and meaningful message so I can > attempt to resolve the issue. > It seems to happen every time so it is very easily reproducible. Thanks for the information. On which operating system do you get this issue? And what region are you from? > > I installed the current version of LibreOffice [Version: 5.4.7.2 (x64)}] and > both program update and extension update work fine (updates are shown when > available). LO update is totally unrelated to our system... > > Thanks, Tracey > OO4.1.5 Updates: Checking for an update failed. > : Error reading data from the Internet. > : Server error message: . > Ext Manager: Error reading data from the Internet. > : Server error message: .
On which operating system do you get this issue? Windows 7 And what region are you from? Eastern United States Thanks, Tracey
Reproduce with AOO 4.1.5 and Windows 7 x64 Pro Localisation: France Set status as confirmed
Reproducable with Windows 10 64bit and Ubuntu 18.04. I tried AOO420m1(Build:9800) - Rev. 1832749 with Windows 10 64bit -> no server error messages.
*** Issue 127791 has been marked as a duplicate of this issue. ***
*** Issue 127798 has been marked as a duplicate of this issue. ***
Reproduced with AOO 4.1.5. and Microsoft Windows 10 64 bit Version 1803 10.0.17134 Build 17134 Language German Country Germany same error: server error message; in German "Serverfehlermeldung ." with Space and point behind. amurtiger77
I forgot: It is Microsoft Windows Home 10 64 bit … and so on, as described
Beside this, recognize please: I have installed all new with complete uninstalling AOO 4.1.5. and new Installation and then Installation Language pack German
*** Issue 127818 has been marked as a duplicate of this issue. ***
*** Issue 127819 has been marked as a duplicate of this issue. ***
*** Issue 127846 has been marked as a duplicate of this issue. ***
*** Issue 127851 has been marked as a duplicate of this issue. ***
My own issue regarding this problem proved to be a duplicate, which was not surprising. I am not convinced that this problem has been fixed. I would like clarity and proof on a resolution to this. I don't intend to completely uninstall and reinstall Openoffice until a new version is available. I would like a direct email address to contact Apache in order to contact them and request a resolution or release date for a new version of OpenOffice. The fact that the issue came on gradually and occurs on both of my computers, using different versions of Windows suggests to me that either a faulty installation was copied from one computer to another, or it waas caused by something else from outside Openoffice, such as Java Runtime Environment (JRE). As I reported on my own issue (127851). My view is that the key to ending this issue is to get an updated version of the Java installer jxpinstall.exe to set up Java the proper way. I would like someone other than myself to use an older version of Java to find out if I am right. Robin Clement.
(In reply to Robin Clement from comment #14) > I would like a direct email address to contact Apache in order > to contact them and request a resolution or release date for a new version > of OpenOffice. There is no direct e-mail. Remember that OpenOffice is a community with only volunteers. Support can be provided through mailing list or forum. Read this: http://www.openoffice.org/support/
*** Issue 127871 has been marked as a duplicate of this issue. ***
*** Issue 127894 has been marked as a duplicate of this issue. ***
I've been having the same issue since the beginning of the year. AOO 4.1.5, Windows 7 Home Premium w/ updates, Western USA. Mozilla Firefox Quantum, Waterfox, & Vivaldi Web Browsers w/ numerous extensions. This failure in 'Check for Updates' used to be intermittent, but now it's chronic no matter if all my User Acct browsers have all their Add-ons updated, which used to make a difference whether or not the 'Check for Updates' would work or not. I have NOT tried to uninstall & re-install AOO 4.1.5. Is this a Java Runtime Environment(JRE) issue? Really need a resolution to what I consider a MAJOR issue.
Although it is not clear if this problem is in our code or related to problems with connecting to our update feed/extension site, I ask for release blocker 4.1.6.
Accepted for 4.1.6
We should consider this a blocker with a grain of salt, meaning that approving as a blocker something that possibly does not depend on the OpenOffice code at all is premature. Most likely this issue is related to network configuration and not to the OpenOffice code. We should still try to investigate it as much as we can, but my bet is that we won't find anything to fix in the OpenOffice code and that any fixes will have to be done on the infrastructure side. For the record, I'm able to reproduce it too, so I can take a look and report back. Let's focus on the OpenOffice updates first, then the extensions updates later.
This interferes with the release process. We have to ensure that update facility works. For that we have to at least locate the issue. If the update process works but the issue cannot be solved fast we can decide in a release bit to remove the Blocker. If we fix this quickly the better. That's my reasoning. Sorry should have wrote it down.
*** Issue 127912 has been marked as a duplicate of this issue. ***
*** Issue 127936 has been marked as a duplicate of this issue. ***
Works if you replace "UpdateURL=https://ooo-updates" in VERSIONRC (Linux) or VERSIONS.INI (Win) with "UpdateURL=http://ooo-updates" So only secure connection fails in 4.1.x In AOO 4.2 dev "UpdateURL=https://ooo-updates" works but it connects to "aoonext" instead of "aoo41x"
It is not recommended to change the update URLs manually. The issue was debugged at length on the dev list last weekend, see https://s.apache.org/Qlej (discussion about updates starts later in the thread). We are going to fix this on the server side, so without any change on the user installations. But indeed the issue is related to the HTTPS/SSL configuration and bundled libraries.
*** Issue 127947 has been marked as a duplicate of this issue. ***
Ditto on my win10/US system for both program and extension updates. Still uncorrected on AOO 4.1.6 after "updating" from 4.1.5 which required a complete un/reinstallation. Extension update checking on 4.1.6 fails also with undefined server error(s).
Due to my autism, I find it difficult to take comprehensive screenshots. I was able to log the last successful update check I did to earlier in 2018. At the time, I already had Openoffice 4.1.5 as I remembered. My suspicion is that the problem is due to changes in Java. In order to fix the problem, you have to have a particular version of Java installed in order to run Openoffice properly. Java has been mentioned as associated with Openoffice. What I have been after to confirm this is an updated version of the jxpinstall.exe Java installation program, which is what I used to download to install Java. My view is that if it is Java, Apache should u-turn and provide a built in Java with Openoffice installation packages.
>In order to fix the problem, you have to have a particular version of Java installed in order to run Open Office properly. I think dependency on java is a big mistake unless you are using the database component. Java is known for constant updates due to security issues (not their fault) I think to do a relatively simple routine that java is just an un-necessary risk. As an End User, I have several software programs that check for updates via the installed web browser and they work just fine without java. Just an observation, Tracey I even think making java necessary to use "find" on the "Open Office Help" is un-necessary. Kinda leans toward bloatware. I am not a great fan of Microsoft per say, but their local Help files have always come with a functional find feature.
(In reply to Tracey from comment #30) > >In order to fix the problem, you have to have a particular version of Java installed in order to run Open Office properly. > > I think dependency on java is a big mistake unless you are using the > database component. This issue has been discussed on dev@ and has *nothing* to do with Java. > I even think making java necessary to use "find" on the "Open Office Help" > is un-necessary. Agreed, but that is another issue...
*** Issue 128043 has been marked as a duplicate of this issue. ***
*** Issue 128068 has been marked as a duplicate of this issue. ***
*** Issue 128187 has been marked as a duplicate of this issue. ***
*** Issue 128196 has been marked as a duplicate of this issue. ***
*** Issue 128210 has been marked as a duplicate of this issue. ***
Still continue with 4.1.7
The office update feed is https://ooo-updates.apache.org/aoo417/check.Update The extensions' update feed is https://extensions.openoffice.org/ExtensionUpdateService/check.Update extensions.openoffice.org supports TLSv1.1 and TLSv1.2 ooo-updates.apache.org supports TLSv1.2 On Linux you can try with the following commands: nmap --script +ssl-enum-ciphers -p 443 ooo-updates.apache.org nmap --script +ssl-enum-ciphers -p 443 extensions.openoffice.org OpenOffice/serf is trying to connect only with TLSv1.0, thus the error: [2019-10-27T13:41:12.526747-03] buckets/ssl_buckets.c: SSL_connect:before/connect initialization [2019-10-27T13:41:12.526903-03] buckets/ssl_buckets.c: bio_bucket_write called for 117 bytes [2019-10-27T13:41:12.526982-03] buckets/ssl_buckets.c: SSL_connect:SSLv2/v3 write client hello A [2019-10-27T13:41:12.527039-03] buckets/ssl_buckets.c: bio_bucket_read called for 7 bytes [2019-10-27T13:41:12.527075-03] buckets/ssl_buckets.c: bio_bucket_read received 0 bytes (70014) [2019-10-27T13:41:12.527135-03] buckets/ssl_buckets.c: SSL_connect:error in SSLv2/v3 read server hello A [2019-10-27T13:41:12.527188-03] buckets/ssl_buckets.c: ssl_encrypt: SSL write: -1 [2019-10-27T13:41:12.527311-03] buckets/ssl_buckets.c: ssl_encrypt: SSL write error: 2 [2019-10-27T13:41:12.527352-03] buckets/ssl_buckets.c: ssl_encrypt: SSL write error: 120103 0 [2019-10-27T13:41:12.527392-03] buckets/ssl_buckets.c: ssl_encrypt read agg: 120103 70014 11 117 [2019-10-27T13:41:12.527437-03] buckets/ssl_buckets.c: ssl_encrypt finished: 120103 117 (8 1 9) This is broken with every server that doesn't support TLSv1.0, a setting quite common nowadays; try for example to open https://bitbucket.org/lifia-oop/practicas-objetos-1/src/master/README.md bitbucket.org supports only TLSv1.2
Created attachment 86932 [details] Screenshot of AOO 3.4.1 (2020-04-26) Actually it is a Regression introduced in branch 4.0 Update checking still works perfectly in AOO 3.4.1 and suggests the correct version.
Both the older pre 4.0 and >= 4.0 update services are hosted on the same apache.org web servers and they only support TLS 1.2 with just a few ciphers. The templates and extensions servers at SourceForge only support TLS 1.2 with many more ciphers. % nmap --script ssl-enum-ciphers -p 443 ooo-updates.apache.org Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-19 12:55 PDT Nmap scan report for ooo-updates.apache.org (40.79.78.1) Host is up (0.073s latency). Other addresses for ooo-updates.apache.org (not scanned): 2a01:4f9:2a:185f::2 95.216.24.32 PORT STATE SERVICE 443/tcp open https | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A | compressors: | NULL | cipher preference: server |_ least strength: A Nmap done: 1 IP address (1 host up) scanned in 4.66 seconds Perhaps this issue is related to the newer updates being rewritten to a different domain name?
Actually - Like Pedro I more suspect that there is a regression in the code.
(In reply to Dave Fisher from comment #41) > Actually - Like Pedro I more suspect that there is a regression in the code. The bug is in the quite old openssl version, but IIRC that was updated in trunk; not sure if it was cherry-picked for 4.1.8
(In reply to Ariel Constenla-Haile from comment #42) > > The bug is in the quite old openssl version, but IIRC that was updated in > trunk; not sure if it was cherry-picked for 4.1.8 Revision 1756954 updated openssl from 0.9.8zh to 1.0.2h, on trunk. 4.1.8 has openssl 0.9.8zh. 1.0.2h is now quite old, the latest LTS is openssl-1.1.1 from April 2020.
No objections against updating openssl but that doesn't help us with the update feed not working for released versions of AOO. Here we need to find a solution on the server side where the generated feeds reside. (BTW: Update feeds work in trunk/AOO42X)
(In reply to Matthias Seidel from comment #44) > No objections against updating openssl but that doesn't help us with the > update feed not working for released versions of AOO. > Here we need to find a solution on the server side where the generated feeds > reside. I'm not sure what the problem with the AOO update servers is, but the reason for the bug described here is that the openssl version included in AOO is too old and is trying to connect with TLSv1.0. There is no way to patch released versions, so the only solution for released versions would be to add support for TLSv1.0 in the servers, but for sure sysadmins wouldn't do that, TLSv1.0 is "actively being deprecated in accordance with guidance from government agencies" https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html > (BTW: Update feeds work in trunk/AOO42X) That's because it has a newer openssl version. But is it working in 4.1.8?
(In reply to Ariel Constenla-Haile from comment #45) > (In reply to Matthias Seidel from comment #44) > I'm not sure what the problem with the AOO update servers is, but the reason > for the bug described here is that the openssl version included in AOO is > too old and is trying to connect with TLSv1.0. Exactly! > There is no way to patch released versions, so the only solution for > released versions would be to add support for TLSv1.0 in the servers, but > for sure sysadmins wouldn't do that, TLSv1.0 is "actively being deprecated > in accordance with guidance from government agencies" > https://tools.ietf.org/id/draft-ietf-tls-oldversions-deprecate-02.html That has been discussed on dev@. Unfortunately we didn't make any progress. A solution would be a single server hosting only the few update feeds. > > (BTW: Update feeds work in trunk/AOO42X) > > That's because it has a newer openssl version. But is it working in 4.1.8? Nothing has changed in this respect in 4.1.8.
The apache servers won't support TLS 1.0 as that is insecure. I've discussed a potential solution with one of the Infra admins, but because that part is a security consideration the discussion will need to continue in private. 4.1.8 must be released with a version of openssl that supports TLS 1.2. Glad we are all the same page here.
Verified fixed both under Windows 7 x64 and Ubuntu 18.04 x64