Hello Matthias, All, On Thu, Jan 06, 2022 at 04:08:23PM +0100, Matthias Seidel wrote:
> 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 <[email protected]> > >>>>>> 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? We do not use NSS for certificate validation under Windows. Class SecurityEnvironment_MSCryptImpl is instantiated instead of SecurityEnvironment_NssImpl. It uses Win32 API functions from header wincrypt.h. Best regards, -- Arrigo --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
