Hi Arrigo,
Am 06.01.22 um 16:04 schrieb Arrigo Marchiori:
> 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.
>
> But we are at least at the point that the serf library seems to be
> successfully integrated and working! I may make some more commits to
> the "serf" branch to synchronize it with my computer.
>
> I think we should integrate the "serf" branch only after the search
> for update is successful, even if the problem, at this moment, may not
> be related to the Serf library itself.
>
> I am of course open to discussion, as always.Any idea why it works on Windows and not on Linux/macOS? Do we access the system-level CA list on Windows somehow? Regards, Matthias > > Best regards,
smime.p7s
Description: S/MIME Cryptographic Signature
