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.
Best regards,
--
Arrigo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
