[GitHub] [openoffice-org] jeanmicoste commented on pull request #62: Create msg_prop_l10n_fr.js

2022-01-07 Thread GitBox


jeanmicoste commented on pull request #62:
URL: https://github.com/apache/openoffice-org/pull/62#issuecomment-1007757141


   Le 07/01/2022 à 19:20, Matthias Seidel a écrit :
   >
   > I think this file already exists:
   > 
https://github.com/apache/openoffice-org/blob/main/assets/fr/download/msg_prop_l10n_fr.js
   >
   > Message ID: ***@***.***>
   
   This file is not fully translated.
   I don't understand anything anymore, there is twice the same structure:
   
   https://github.com/apache/openoffice-org/tree/main/assets/fr
   
   and
   
   https://github.com/apache/openoffice-org/tree/main/content/fr
   
   it was in the second that I made the first corrections.
   
   I no longer know where I should intervene, nor which one I see here :
   
   https://openoffice-org.staged.apache.org/fr/
   
   Regards,
   
   -- 
   
   
   Jean-Michel COSTE
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[GitHub] [openoffice-org] Pilot-Pirx commented on pull request #62: Create msg_prop_l10n_fr.js

2022-01-07 Thread GitBox


Pilot-Pirx commented on pull request #62:
URL: https://github.com/apache/openoffice-org/pull/62#issuecomment-1007629894


   I think this file already exists:
   
https://github.com/apache/openoffice-org/blob/main/assets/fr/download/msg_prop_l10n_fr.js
   
   Your translated file is in the wrong location.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



[GitHub] [openoffice-org] jeanmicoste opened a new pull request #62: Create msg_prop_l10n_fr.js

2022-01-07 Thread GitBox


jeanmicoste opened a new pull request #62:
URL: https://github.com/apache/openoffice-org/pull/62


   Use by several files.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Openssl, serf and curl... and NSS

2022-01-07 Thread Peter Kovacs



On 07.01.22 13:47, Arrigo Marchiori wrote:

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 +, Pedro Lino wrote:


Hi Matthias


On 12/09/2021 3:20 PM Matthias Seidel  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.


sure, it is a dependency we have to maintain of some sort. Since we will 
not use the edge Version.


So I thought if it is not working we could try to make it obsolete. But 
you got it otherwise. nice.




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

cool if it works merge it.


Best regards,

--
This is the Way! http://www.apache.org/theapacheway/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Project Planning page on cwiki

2022-01-07 Thread Marcus

Am 07.01.22 um 12:32 schrieb Arrigo Marchiori:

On Wed, Jan 05, 2022 at 07:03:47PM +0100, Marcus wrote:

Am 05.01.22 um 10:09 schrieb Arrigo Marchiori:

On Sat, Nov 06, 2021 at 11:57:14AM +0100, Marcus wrote:

Am 24.10.21 um 16:27 schrieb Peter Kovacs:

On 24.10.21 16:13, Arrigo Marchiori wrote:

this may have been raised many other times... but why do we keep
publishing release notes under the "Project Planning" cwiki page [1]
when that page starts with a big warning that is only for the
incubation phase? :-)

I think there are a lot of old an new stuff intermixed. We have left the
existing stuff as is and added the new stuff.

My humble suggestion, given the fact that the section contains updated
information, is to create a subpage "Incubation" and then move under
it all subpages related to the incubation period.

I am available to do this work, if no one else has either better ideas
or good reasons not to do so.


Sounds like an improvement. I have no objection. :)


[1]:
https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning


indeed. In the meantime outdated and it could be improved.

As a first step I've deleted the warning.

When you have some concret points that should be improved just tell here or
start in Confluence and we can talk about it.


I suggest we create an "Incubation" subpage of "Project planning" and
move ("reparent"?) into there:


sounds good. We should add a short explaintion text, so tht everyone knows
what can be expected on this and all subpages.


   - Site-PPMC-Plan
   - Site-QA-Plan
   - Site-Dev-Plan
   - IP_Clearance
   - Assigned issues to former Oracle employee
   - ...all other pages explicitly referring to the OpenOffice.org migration

I understand these are somewhat major changes so I want to make sure
no one has objections before starting to implement them.


Thanks for asking. If you need help in or with Confluence please don't
hesitate to ask.


Thank you. I am done now.

The "older" pages are now under
https://cwiki.apache.org/confluence/display/OOOUSERS/Incubation


oh, that was fast.

I've add a sentence that the Incubation phase is already finished.

Marcus


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Reporting broken download link

2022-01-07 Thread Matthias Seidel
Hi Peter,

Am 07.01.22 um 07:37 schrieb Peter Kovacs:
>
> On 06.01.22 16:09, Matthias Seidel wrote:
>>
>> Hi,
>>
>> Am 06.01.22 um 15:28 schrieb Wang Xiancheng:
>>> You are right, Matthias.
>>
>> Good to know!
>>
>> And another thing that needs to be fixed... ;-)
>>
> Do we have a Ticket for this? Could it be related to Issue 125255 [1]?

I think you forgot the link? ;-)

https://bz.apache.org/ooo/show_bug.cgi?id=125255

That may be the same problem, but I am not really sure.

Since this is related to AOO update which is broken at the moment, maybe
we should wait until that is fixed?

Regards,

   Matthias

>
>
>> Regards,
>>
>>    Matthias
>>
>>>
>>> Best Regards.
>>>
>>> On 01/6/2022 21:39,Matthias Seidel
>>>  wrote:
>>>
>>>     Hi all,
>>>
>>>     The problem seems to be AOO looking for updates. An error occurs
>>>     and AOO
>>>     will be closed.
>>>
>>>     On macOS go to menu "OpenOffice - Preferences - OpenOffice - Online
>>>     Update" and disable "Check for updates automatically".
>>>
>>>     That should help.
>>>
>>>     Regards,
>>>
>>>        Matthias
>>>
>>>     Am 06.01.22 um 14:15 schrieb Peter Kovacs:
>>>
>>>     Have you confirmed that the application is what you want to
>>>     use in
>>>     respect of the Gatekeeper?
>>>
>>>     See:
>>>    
>>> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.1.11+Release+Notes
>>>
>>>     Section: For macOS users
>>>
>>>
>>>     BTW, since you are writing to the development list. You are
>>>     not maybe
>>>     willing to help to translate Apache OpenOffice to your
>>> language?
>>>
>>>     We could use translators. For example we do not have Release
>>>     Notes in
>>>     Chinese.
>>>
>>>
>>>     All the best
>>>
>>>     Peter
>>>
>>>
>>>     On 06.01.22 12:00, Wang Xiancheng wrote:
>>>
>>>     Hi Peter,
>>>     thanks for your kindly help.
>>>     I know where the problem is.  For I am in China. I used
>>>     VPN and it is
>>>     OK to download.
>>>
>>>     But I found that the OpenOffice 4.1.11 can not work well
>>>     on MacOS, it
>>>     will exit after a while when I open it.
>>>
>>>     Best Regards.
>>>
>>>     On 01/6/2022 16:10,Peter Kovacs
>>>      wrote:
>>>
>>>         try https instead of http:
>>>
>>>     https://www.openoffice.org/zh-cn/download/
>>>
>>>
>>>         On 06.01.22 01:42, Xiancheng Wang wrote:
>>>
>>>         Dear Sir/Madam,
>>>         I can’t download the openoffice from
>>>     http://www.openoffice.org/zh-cn/download/
>>>
>>>         Would you please help me?
>>>
>>>         The error from browser is:
>>>         ERR_CONNECTION_REFUSED
>>>
>>>
>>>         Problem description  Exchange this text to
>>>     describe the problem
>>>
>>>         (What does not work? What do you expect?)
>>>         Browser variables  Values
>>>         navigator.appCodeName  Mozilla
>>>         navigator.appName  Netscape
>>>         navigator.appVersion  5.0 (Macintosh)
>>>         navigator.platform  MacIntel
>>>         navigator.oscpu  Intel Mac OS X 10.15
>>>         navigator.cpuClass  undefined
>>>         navigator.product  Gecko
>>>         navigator.productSub  20100101
>>>         navigator.vendor
>>>         navigator.vendorSub
>>>         navigator.language  zh-CN
>>>         navigator.browserLanguage  undefined
>>>         navigator.userLanguage  undefined
>>>         navigator.systemLanguage  undefined
>>>         navigator.userAgent  Mozilla/5.0 (Macintosh;
>>>     Intel Mac OS X
>>>         10.15; rv:95.0) Gecko/20100101 Firefox/95.0
>>>         Debian / Ubuntu / IceWeasel ?  No / No / No
>>>         Stable Release
>>>         JavaScript functions/variables  Values
>>>         Language ISO code  zh-CN
>>>         Language ISO code (from select box)  zh-CN
>>>         Release matrix platform position (full)  9
>>>         Release matrix platform position (lp)  10
>>>         Release matrix platform array data  y,153
>>>         Release matrix language array data  zh-CN,Chinese
>>>         (simplified),简体中文,y,zh-cn/download/
>>>         UI platform name  OS X (version >= 10.7) (DMG)
>>>         UI platform name (not supported)
>>>         Platform (short)  mac64
>>>         URL platform name (full)  MacOS_x86-64_install
>>>         URL platform name (lp)  MacOS_x86-64_langpack
>>>      

Re: problem reading old XML formats with trunk

2022-01-07 Thread Arrigo Marchiori
Hello Carl, All,

I am branching the thread from here in order to prune less
interesting parts.

On Sun, Nov 14, 2021 at 10:12:05PM -0500, Carl Marcum wrote:

> Hi All,
> 
> On 11/14/21 5:05 PM, Matthias Seidel wrote:
> > Hi Carl,
> > 
> > Am 14.11.21 um 22:45 schrieb Carl Marcum:
> > > Hi Matthias,
> > > 
> > > 
> > > On 11/14/21 11:44 AM, Matthias Seidel wrote:
> > > > Hi Carl,
> > > > 
> > > > Am 14.11.21 um 17:36 schrieb Matthias Seidel:
> > > > > Hi Carl,
> > > > > 
> > > > > Am 14.11.21 um 17:31 schrieb Carl Marcum:
> > > > > > Hi Matthias and All,
> > > > > > 
> > > > > > On 11/14/21 9:10 AM, Matthias Seidel wrote:
> > > > > > > Hi Carl,
> > > > > > > 
> > > > > > > I only have a VM available with Xubuntu 18.04.6 and AOO42X, but
> > > > > > > have no
> > > > > > > problems opening and saving *.STW.
> > > > > > Okay I'll build AOO42X and see if I have same issues as trunk.
> > > > > > 
> > > > > > I recompiled trunk with
> > > > > > --enable-crashdump=yes \
> > > > > > --enable-dbgutil \
> > > > > > 
> > > > > > and now I get a better error dialog for opening these file types:
> > > > > > testSaveNewSTC.stc
> > > > > > testSaveNewSXC.sxc
> > > > > > --
> > > > > > Error: uno exception caught while importing:
> > > > > > attempt to insert duplicate XML tag attribute: xmlns:svg
> > > > > >   From File
> > > > > > /openoffice/main/sc/source/filter/xml/xmlwrap.cxx at
> > > > > > Line 365
> > > > > > Abort ? (Yes=abort / No=ignore / Cancel=core dump)
> > > > > I remember that we have a commit in trunk but not in AOO42X:
> > > > > 
> > > > > https://github.com/apache/openoffice/pull/122
> > > > > 
> > > > > Until now it has not been tested... Maybe that is the problem?
> > > > I can confirm Read-Errors with AOO450 (trunk) on Windows with STW and
> > > > SXW.
> > > > No problems with AOO420 (AOO42X).
> > > > 
> > > > This merge may need to be reverted...
> > > 
> > > Thanks for checking.
> > > 
> > > It might be better at this point to fix the code.
> > That's why I asked for testing... ;-)
> > > I'll do some bisecting and try to narrow it down.
> > I am not sure if the code was ready, Arrigo might know better.
> 
> I bisected it down to this one where it starts giving me the error which
> makes sense according the the commit message:
> 
> ebd28ad3a7fedadb378ee1596803008e8c6b383b is the first bad commit
> commit ebd28ad3a7fedadb378ee1596803008e8c6b383b
> 
>     Raise an exception when attempting to add duplicate attributes

The error is raised during parsing of file styles.xml, initial tag
, attribute
xmlns:svg="http://openoffice.org/2000/svg;

Method XMLDocumentTransformerContext_Impl::StartElement() considers
individual XML attributes and, at the end, it adds the ones it
considers missing.

The xmlns:svg is considered missing because it does not have the
expected _content_. Yes, the check is made on attribute contents,
rather than attribute names.

That attributs's content _should_ be the one indicated above, but the
caller method XMLTransformerBase::startElement() has _just changed its
content_ into
"urn:oasis:names:tc:opendocument:xmlns:svg-compatible:1.0"

For this reason, method
XMLDocumentTransformerContext_Impl::StartElement() tries to re-add the
"xmlns:svg" element.

The first solutions that come into my mind are:

 1- have XMLDocumentTransformerContext_Impl::StartElement() consider
 element _names_ rather than values, or

 2- have XMLDocumentTransformerContext_Impl::StartElement() look for
 the ``changed'' content (urn:etcetera) instead of the ``original''
 one (http://Etcetera)

What is the best way to go?

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Openssl, serf and curl... and NSS

2022-01-07 Thread Matthias Seidel
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 +, Pedro Lino wrote:
>>
>>> Hi Matthias
>>>
 On 12/09/2021 3:20 PM Matthias Seidel  
 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


Re: Openssl, serf and curl... and NSS

2022-01-07 Thread 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 +, Pedro Lino wrote:
> > > > > 
> > > > > > Hi Matthias
> > > > > > 
> > > > > > > On 12/09/2021 3:20 PM Matthias Seidel 
> > > > > > >  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,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



Re: Project Planning page on cwiki

2022-01-07 Thread Arrigo Marchiori
Hello Marcus, All,

On Wed, Jan 05, 2022 at 07:03:47PM +0100, Marcus wrote:

> Am 05.01.22 um 10:09 schrieb Arrigo Marchiori:
> > On Sat, Nov 06, 2021 at 11:57:14AM +0100, Marcus wrote:
> > 
> > > Am 24.10.21 um 16:27 schrieb Peter Kovacs:
> > > > On 24.10.21 16:13, Arrigo Marchiori wrote:
> > > > > this may have been raised many other times... but why do we keep
> > > > > publishing release notes under the "Project Planning" cwiki page [1]
> > > > > when that page starts with a big warning that is only for the
> > > > > incubation phase? :-)
> > > > I think there are a lot of old an new stuff intermixed. We have left the
> > > > existing stuff as is and added the new stuff.
> > > > > My humble suggestion, given the fact that the section contains updated
> > > > > information, is to create a subpage "Incubation" and then move under
> > > > > it all subpages related to the incubation period.
> > > > > 
> > > > > I am available to do this work, if no one else has either better ideas
> > > > > or good reasons not to do so.
> > > > 
> > > > Sounds like an improvement. I have no objection. :)
> > > > 
> > > > > [1]:
> > > > > https://cwiki.apache.org/confluence/display/OOOUSERS/Project+Planning
> > > 
> > > indeed. In the meantime outdated and it could be improved.
> > > 
> > > As a first step I've deleted the warning.
> > > 
> > > When you have some concret points that should be improved just tell here 
> > > or
> > > start in Confluence and we can talk about it.
> > 
> > I suggest we create an "Incubation" subpage of "Project planning" and
> > move ("reparent"?) into there:
> 
> sounds good. We should add a short explaintion text, so tht everyone knows
> what can be expected on this and all subpages.
> 
> >   - Site-PPMC-Plan
> >   - Site-QA-Plan
> >   - Site-Dev-Plan
> >   - IP_Clearance
> >   - Assigned issues to former Oracle employee
> >   - ...all other pages explicitly referring to the OpenOffice.org migration
> > 
> > I understand these are somewhat major changes so I want to make sure
> > no one has objections before starting to implement them.
> 
> Thanks for asking. If you need help in or with Confluence please don't
> hesitate to ask.

Thank you. I am done now.

The "older" pages are now under
https://cwiki.apache.org/confluence/display/OOOUSERS/Incubation

Best regards,
-- 
Arrigo

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org