Hi all, +1 for fixing the macOS issues and merging PR100.
Regards, Matthias Am 07.01.22 um 13:47 schrieb Arrigo Marchiori: > Hello Peter, All, > > On Thu, Jan 06, 2022 at 09:34:22PM +0100, Peter Kovacs wrote: > >> On 06.01.22 16:04, Arrigo Marchiori wrote: >>> Dear All, >>> >>> On Thu, Jan 06, 2022 at 03:02:21PM +0100, Arrigo Marchiori wrote: >>> >>>> Dear All, >>>> >>>> On Wed, Jan 05, 2022 at 05:03:44PM +0100, Arrigo Marchiori wrote: >>>> >>>>> Dear All, >>>>> >>>>> one more status update. >>>>> >>>>> On Sat, Dec 25, 2021 at 09:57:03PM +0100, Arrigo Marchiori wrote: >>>>> >>>>>> Dear All, >>>>>> >>>>>> first of all: merry Christmas! >>>>>> >>>>>> On Thu, Dec 09, 2021 at 06:00:58PM +0000, Pedro Lino wrote: >>>>>> >>>>>>> Hi Matthias >>>>>>> >>>>>>>> On 12/09/2021 3:20 PM Matthias Seidel <matthias.sei...@hamburg.de> >>>>>>>> wrote: >>>>>>>> Is this a real machine or a VM? >>>>>>> It is a real machine >>>>>>>> I ask, because I have seen the Update Feed fail on Ubuntu in a VM when >>>>>>>> it definitely worked on my Laptop. >>>>>>> There were a lot of errors during unpack, as I said. >>>>>> What kind of errors? Maybe permission issues? >>>>>> I hope I will eventually get a trunk build right for everyone... >>>>>> >>>>>> By the way the problem _under Linux_ may or may not be due to >>>>>> TLS... in fact the error message is "Device or resource busy". There >>>>>> is something _inside_ serf that is failing; I am not sure it is a >>>>>> network protocol issue. >>>>>> >>>>>> I am looking into this issue in my available time. >>>>> It's true that the returned value (16) corresponds to "Device or >>>>> resource busy"... but it _also_ corresponds to >>>>> SERF_SSL_CERT_UNKNOWN_FAILURE ! And _this_ is the error! >>>>> >>>>> This error is raised during the verification of the SSL certificate >>>>> chain. We are in method SerfSession::verifySerfCertificateChain(). >>>>> Apparently, we have a certificate with subject "CN=*.apache.org" and >>>>> we are asking our certificate container if it "has" and "trusts" such >>>>> certificate for URL ooo-updates.apache.org. >>>>> >>>>> The call (simply described) is: >>>>> CertificateContainer::hasCertificate("ooo-updates.apache.org", >>>>> "*.apache.org") >>>>> >>>>> Surprisingly (to me at least), this returns >>>>> security::CertificateContainerStatus_UNTRUSTED >>>>> >>>>> This breaks the update request process. >>>> The culprit is the nss library. Our method >>>> SecurityEnvironment_NssImpl::verifyCertificate calls >>>> CERT_PKIXVerifyCert() that returns failure. The reason is error -8172, >>>> "Peer's certificate issuer has been marked as not trusted by the user." >>> The problem is that NSS does not have access to an updated list of >>> certification authorities. >>> >>> NSS has its own built-in list of CA's that is stored inside library >>> libnssckbi.so. Such list does not include the CA used by our update >>> server. For this reason, the check for updates fails as described. >>> >>> There are two possible solutions, given the fact that we may not be >>> able to update our NSS to the latest and greatest version: >>> >>> 1- patch the latest CA list from current NSS into our NSS. I did it >>> for the purpose of this development, and... it is horrible. We have >>> to shave away some attributes that are not supported by our NSS: >>> - CKA_NSS_SERVER_DISTRUST_AFTER >>> - CKA_NSS_EMAIL_DISTRUST_AFTER >>> - CKA_NSS_MOZILLA_CA_POLICY >>> and I would not feel ``safe'' for our end-users if we did so. >>> >>> 2- try to access the system-level CA list, that every system should >>> have. >>> >>> I think that 2- is the way to go. >> Just an unqalified question, can we use OpenSSL instead? > I am not sure how much the functionalities of NSS and OpenSSL overlap. > > It is true that we already have a codebase supporting NSS, and that > NSS is fairly widespread IMHO. If possible, I prefer remaining with > NSS. > > And... you know what? > > Don Lewis' proposed update to NSS seem to fix this problem! > If I build from his branch, I get the much awaited "already up to > date" message! > Proof: > https://home.apache.org/~ardovm/openoffice/linux/openoffice4-nss-x86_64-2022-01-07-installed.tar.bz2 > > So, the way to go is probably the one I had just excluded in the first > place: > > 0- update NSS as per https://github.com/apache/openoffice/pull/100 > > Best regards,
smime.p7s
Description: S/MIME Cryptographic Signature