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,

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to