Release Manager for 4.2.0?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Release Manager for 4.2.0?

Andrea Pescetti-2
As I wrote a few day ago, in theory it would be good to release
OpenOffice 4.2.0 in February. If it happens a bit later it wouldn't be a
big issue, but I believe that, in the constant balance between periods
where we are focused on talks (internal to OpenOffice and with the
enlarged community) and periods where we are more focused on the
OpenOffice product, it's time to start working again towards a release.

For 4.2.0 we need a Release Manager. I would prefer NOT to be the
Release Manager for 4.2.0 since I'm finding that in this period I can
help more productively with tasks that do not require constant
interaction than with tasks that require a constant monitoring of
project channels.

I am surely available to have a significant role in the 4.2.0 release,
especially with getting localization working again (actually, this mail
also serves as announcement that I am going to ask for higher privileges
on the Pootle server in order to check the translation workflow); but if
someone else steps in as a Release Manager we could deliver earlier.

So if anyone is interested feel free to discuss this on list, or to
contact me off-list if you prefer, or to discuss in person at FOSDEM
next weekend!

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Andrea Pescetti-2
On 29/01/2016 Andrea Pescetti wrote:
> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> Release Manager for 4.2.0 since I'm finding that in this period I can
> help more productively with tasks that do not require constant
> interaction ...
> I am surely available to have a significant role in the 4.2.0 release

A few days after writing this, almost 2 months ago, sudden events left
me incapacitated to make any significant contributions until very
recently. I'm still unable to make long-term commitments.

Anyway, there are some issues we need to get done as a team before
appointing a release manager makes sense:

1) Enough code. Done. The merge of the recent gbuild work totally
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
fraction of the fixes that (at that time) were available on trunk. So
here we are already OK, and we've been OK for months.

2) Localization. I got shell access to the Pootle server a few days ago.
I'm still looking around, and if someone else want to join this is an
important part. We need to have a solid process for updating
translations (the full route: new strings in code -> Pootle -> back to
code -> in localized builds) in place.

3) Buildbots and ASF-owned build machines. Buildbots are not essential
for a release: 4.1.2 was built (like all previous releases in history)
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
can't use buildbots for it; we need to setup new systems. Those who read
the infrastructure@ list can see the discussion I started there
yesterday. Still, having buildbots helps QA and having ASF-owned build
machines is an important investment for the project: at that point we
will be able to make a release within days, not months. We should make
as much progress as we can here. Again, if anybody can help, this is an
important area.

4) There are several optimizations I have in mind, especially on
reducing a bit our binary size on Linux (trust me, it is really a pain
to commit all those binaries to SVN, or to any version control system).
But they are not essential.

I have just committed to the devtools/ area the scripts we (mainly
Juergen) used to build the 4.1.2 release, with specs of the build
machines. I've had them since last October, but I never committed them.
They are a first step if we want to build our release binaries on ASF
hardware: they contain build options and config.log to have some more
information on the environment.

My next priorities will be localization (especially, re-exporting the
Italian translation to Pootle and re-importing it) and and a
proof-of-concept VM for building releases on Linux (64 bit) based on the
above scripts. There is plenty of room for other to jump in (Linux 32,
Windows, Mac; or localization management) so please do!

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Release Manager for 4.2.0?

Dennis E. Hamilton
Great news!

Thanks, Andrea

> -----Original Message-----
> From: Andrea Pescetti [mailto:[hidden email]]
> Sent: Sunday, March 27, 2016 13:13
> To: [hidden email]
> Subject: Re: Release Manager for 4.2.0?
>
> On 29/01/2016 Andrea Pescetti wrote:
> > For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> > Release Manager for 4.2.0 since I'm finding that in this period I can
> > help more productively with tasks that do not require constant
> > interaction ...
> > I am surely available to have a significant role in the 4.2.0 release
>
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
>
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
>
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.
>
> 2) Localization. I got shell access to the Pootle server a few days ago.
> I'm still looking around, and if someone else want to join this is an
> important part. We need to have a solid process for updating
> translations (the full route: new strings in code -> Pootle -> back to
> code -> in localized builds) in place.
>
> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
> for a release: 4.1.2 was built (like all previous releases in history)
> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
> can't use buildbots for it; we need to setup new systems. Those who read
> the infrastructure@ list can see the discussion I started there
> yesterday. Still, having buildbots helps QA and having ASF-owned build
> machines is an important investment for the project: at that point we
> will be able to make a release within days, not months. We should make
> as much progress as we can here. Again, if anybody can help, this is an
> important area.
>
> 4) There are several optimizations I have in mind, especially on
> reducing a bit our binary size on Linux (trust me, it is really a pain
> to commit all those binaries to SVN, or to any version control system).
> But they are not essential.
>
> I have just committed to the devtools/ area the scripts we (mainly
> Juergen) used to build the 4.1.2 release, with specs of the build
> machines. I've had them since last October, but I never committed them.
> They are a first step if we want to build our release binaries on ASF
> hardware: they contain build options and config.log to have some more
> information on the environment.
>
> My next priorities will be localization (especially, re-exporting the
> Italian translation to Pootle and re-importing it) and and a
> proof-of-concept VM for building releases on Linux (64 bit) based on the
> above scripts. There is plenty of room for other to jump in (Linux 32,
> Windows, Mac; or localization management) so please do!
>
> Regards,
>    Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Don Lewis-2
In reply to this post by Andrea Pescetti-2
On 27 Mar, Andrea Pescetti wrote:

> On 29/01/2016 Andrea Pescetti wrote:
>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>> Release Manager for 4.2.0 since I'm finding that in this period I can
>> help more productively with tasks that do not require constant
>> interaction ...
>> I am surely available to have a significant role in the 4.2.0 release
>
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
>
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
>
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.

Some of the external software that is bundled has security issues.  I
put together a patch for nss here:
<https://bz.apache.org/ooo/show_bug.cgi?id=126891>.

The version of libxml currently bundled also has a lot of known
vulnerabilities.  I'm currently testing a patch.

These both need review and testing.

The versions of openssl and curl badly need updating for the same
reason, and there is one CVE for serf.

There is a CVE for raptor-1.4.18, but I believe there was a cherry
picked patch commited for that.

There are likely to be vulnerabilites in the bundled version of
silgraphite, but it has been unmaintained upstream for quite some time.
Ideally we would switch to Graphite2, but the API is radically different
and this looks difficult.  The unattractive alternative is to look at
the additional sanity checks added in recent Graphite2 commits and try
to retrofit those into silgraphite.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Pedro Giffuni
In reply to this post by Andrea Pescetti-2
In reply to Don,

FWIW, On the topic of updates
...

> Some of the external software that is bundled has security issues.  I
> put together a patch for nss here:
> <https://bz.apache.org/ooo/show_bug.cgi?id=126891>.
>
> The version of libxml currently bundled also has a lot of known
> vulnerabilities.  I'm currently testing a patch.
>
> These both need review and testing.
>
> The versions of openssl and curl badly need updating for the same
> reason, and there is one CVE for serf.

FreeBSD casually keeps some backported updates for the same openssl
version AOO uses:

https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log

It should be pretty straightforward to take them from there and use them
into
main/openssl with minor adaptions.

Pedro.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Don Lewis-2
On 28 Mar, Pedro Giffuni wrote:
> In reply to Don,

>> The versions of openssl and curl badly need updating for the same
>> reason, and there is one CVE for serf.
>
> FreeBSD casually keeps some backported updates for the same openssl
> version AOO uses:
>
> https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>
> It should be pretty straightforward to take them from there and use them
> into
> main/openssl with minor adaptions.

That would fix only part of the problem.  The other part of the problem
is that the version of openssl that we currently bundle doesn't
implement the newer and more secure protocols and ciphers.  The older
and less secure ones are gradually getting disabled on the server side.

For instance, my only copy of Windows is XP, and the last version of IE
released for XP can no longer connect to some web sites because they
have disabled all of the protocols that IE supports.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Pedro Giffuni
In reply to this post by Pedro Giffuni
Hi Don;

> On 28 Mar, Pedro Giffuni wrote:
> > In reply to Don,
>
> >> The versions of openssl and curl badly need updating for the same
> >> reason, and there is one CVE for serf.
> >
> > FreeBSD casually keeps some backported updates for the same openssl
> > version AOO uses:
> >
> > https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
> >
> > It should be pretty straightforward to take them from there and use
> them
> > into
> > main/openssl with minor adaptions.
>
> That would fix only part of the problem.  The other part of the problem
> is that the version of openssl that we currently bundle doesn't
> implement the newer and more secure protocols and ciphers.  The older
> and less secure ones are gradually getting disabled on the server side.
>
> For instance, my only copy of Windows is XP, and the last version of IE
> released for XP can no longer connect to some web sites because they
> have disabled all of the protocols that IE supports.
>

That is a valid concern, however I am unsure about what in OpenOffice
uses the new cyphers. I think OpenSSL is used for signing documents:
when we update OpenSSL will AOO automatically accept more signing
options? I would expect browsers will bring their own SSL
implementations.

TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
further because the newer versions have more code but also more
vulnerabilities, therefore the expected maintenance cost would be
higher.  The FreeBSD 9.x updates are only a temporary workaround.
Now that upstream is not maintaining the older 0.9.8 version
it probably makes sense to reconsider upgrading.

Pedro.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Don Lewis-2
On 28 Mar, Pedro Giffuni wrote:

> Hi Don;
>
>> On 28 Mar, Pedro Giffuni wrote:
>> > In reply to Don,
>>
>> >> The versions of openssl and curl badly need updating for the same
>> >> reason, and there is one CVE for serf.
>> >
>> > FreeBSD casually keeps some backported updates for the same openssl
>> > version AOO uses:
>> >
>> > https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>> >
>> > It should be pretty straightforward to take them from there and use
>> them
>> > into
>> > main/openssl with minor adaptions.
>>
>> That would fix only part of the problem.  The other part of the problem
>> is that the version of openssl that we currently bundle doesn't
>> implement the newer and more secure protocols and ciphers.  The older
>> and less secure ones are gradually getting disabled on the server side.
>>
>> For instance, my only copy of Windows is XP, and the last version of IE
>> released for XP can no longer connect to some web sites because they
>> have disabled all of the protocols that IE supports.
>>
>
> That is a valid concern, however I am unsure about what in OpenOffice
> uses the new cyphers. I think OpenSSL is used for signing documents:
> when we update OpenSSL will AOO automatically accept more signing
> options? I would expect browsers will bring their own SSL
> implementations.

I don't know what OpenOffice uses it for, either, but I would expect
that it also gets used for downloading extensions.  I hadn't even
thought about signatures.  That's something I haven't exercised it at
all.

> TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
> further because the newer versions have more code but also more
> vulnerabilities, therefore the expected maintenance cost would be
> higher.  The FreeBSD 9.x updates are only a temporary workaround.
> Now that upstream is not maintaining the older 0.9.8 version
> it probably makes sense to reconsider upgrading.

And using FreeBSD 9.x as a patch source will not work past the end of
this year because of the FreeBSD 9 EOL.

The FreeBSD OpenOffice port uses --with-system-openssl, and when I build
it for my own use, I set WITH_OPENSSL_PORT=yes, so I am always using the
latest and greatest openssl release.  I haven't run into any problems
with it.  I just signed a document with it ;-)



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Release Manager for 4.2.0?

Dennis E. Hamilton
In reply to this post by Pedro Giffuni
Commenting just on document signing ...

> -----Original Message-----
> From: Pedro Giffuni [mailto:[hidden email]]
> Sent: Monday, March 28, 2016 13:48
> To: OOo Apache <[hidden email]>
> Subject: Re: Release Manager for 4.2.0?
[ ... ]
>
> [ ... ] I am unsure about what in OpenOffice
> uses the new cyphers. I think OpenSSL is used for signing documents:
> when we update OpenSSL will AOO automatically accept more signing
> options? I would expect browsers will bring their own SSL
> implementations.
[orcmid]

The document signature support in Apache OpenOffice is based on XML Digital Signatures Second Edition, <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>. This has nothing to do with communications via secure sockets of course.  Granted that OpenSSL provides library functions for more than that, there is still very limited use for signing documents.

X.509 digital certificates are employed.  XadES extensions may be used (impacting metadata information mainly and only implemented by Microsoft in ODF as far as I know).  Depending on the platform the operating-system secure store for the signing key will usually be employed, so there is operating-system integration.  (This is definitely true for Windows.)

Basically, SHA-1 digests of each part within the ODF package (a Zip) are incorporated in the signature file in a <SignedInfo> element.  That element is effectively what is signed using method RSA-SHA1.  The <SignatureValue> element provides the encrypted details by which the <SignedInfo> can be verified.  This information can be decrypted and checked using the public key certificate of the signer that is included in the signature file.  (These certificates have their own cryptographic verification.)

There are no other methods for the signature data and its signing.

PS. The encryption of ODF files is very different and independent of the signature mechanism.  It is password-based and it uses Blowfish 8-bit CFB mode by default, encrypting each part of the ODF package separately.  Signing of encrypted files is done after encryption.  There is an optional AES-256 usage as well.  That is not produced by Apache OpenOffice.  


>
> TBH, when I updated OpenSSL in AOO, I intentionally didn't upgrade it
> further because the newer versions have more code but also more
> vulnerabilities, therefore the expected maintenance cost would be
> higher.  The FreeBSD 9.x updates are only a temporary workaround.
> Now that upstream is not maintaining the older 0.9.8 version
> it probably makes sense to reconsider upgrading.
>
> Pedro.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Don Lewis-2
On 28 Mar, Dennis E. Hamilton wrote:

> Commenting just on document signing ...
>
>> -----Original Message-----
>> From: Pedro Giffuni [mailto:[hidden email]]
>> Sent: Monday, March 28, 2016 13:48
>> To: OOo Apache <[hidden email]>
>> Subject: Re: Release Manager for 4.2.0?
> [ ... ]
>>
>> [ ... ] I am unsure about what in OpenOffice
>> uses the new cyphers. I think OpenSSL is used for signing documents:
>> when we update OpenSSL will AOO automatically accept more signing
>> options? I would expect browsers will bring their own SSL
>> implementations.
> [orcmid]
>
> The document signature support in Apache OpenOffice is based on XML
> Digital Signatures Second Edition,
> <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>. This has
> nothing to do with communications via secure sockets of course.
> Granted that OpenSSL provides library functions for more than that,
> there is still very limited use for signing documents.
>
> X.509 digital certificates are employed.  XadES extensions may be used
> (impacting metadata information mainly and only implemented by
> Microsoft in ODF as far as I know).  Depending on the platform the
> operating-system secure store for the signing key will usually be
> employed, so there is operating-system integration.  (This is
> definitely true for Windows.)

OpenSSL also provides libcrypto which contains functions for creating,
validating, and using certificates.  It uses some of this functionality
to verify that a secure socket connection is actually connected to the
desired remote endpoint.  I've used to the openssl command line tool to
produce a certificate that was used to authenticate a connection from a
local application to a remote service.

There seems to be a standard place to store certificates under a user's
home directory in the *nix world.  A while back I signed up for a
service that requires updates from me to be signed with a certificate
that they created for me and that my browser downloaded and stashed away
somewhere.  When I tried signing a document with OpenOffice, it found
this certificate and offered it as a choice for signing.

Since OpenOffice also uses curl, which is used for downloading files,
and curl uses OpenSSL, it looks like OpenOffice depends on OpenSSL for
secure downloads.  I don't know if it downloads anything other than
extensions and updates.





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Kay Schenk-2
In reply to this post by Don Lewis-2


On 03/27/2016 03:37 PM, Don Lewis wrote:

> On 27 Mar, Andrea Pescetti wrote:
>> On 29/01/2016 Andrea Pescetti wrote:
>>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>>> Release Manager for 4.2.0 since I'm finding that in this period I can
>>> help more productively with tasks that do not require constant
>>> interaction ...
>>> I am surely available to have a significant role in the 4.2.0 release
>>
>> A few days after writing this, almost 2 months ago, sudden events left
>> me incapacitated to make any significant contributions until very
>> recently. I'm still unable to make long-term commitments.
>>
>> Anyway, there are some issues we need to get done as a team before
>> appointing a release manager makes sense:
>>
>> 1) Enough code. Done. The merge of the recent gbuild work totally
>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
>> fraction of the fixes that (at that time) were available on trunk. So
>> here we are already OK, and we've been OK for months.
>
> Some of the external software that is bundled has security issues.  I
> put together a patch for nss here:
> <https://bz.apache.org/ooo/show_bug.cgi?id=126891>.
>
> The version of libxml currently bundled also has a lot of known
> vulnerabilities.  I'm currently testing a patch.
>
> These both need review and testing.

Ok, I'll keep my eyes open for the libxml patch and test
with your already supplied nss patch.


>
> The versions of openssl and curl badly need updating for the same
> reason, and there is one CVE for serf.
>
> There is a CVE for raptor-1.4.18, but I believe there was a cherry
> picked patch commited for that.
>
> There are likely to be vulnerabilites in the bundled version of
> silgraphite, but it has been unmaintained upstream for quite some time.
> Ideally we would switch to Graphite2, but the API is radically different
> and this looks difficult.  The unattractive alternative is to look at
> the additional sanity checks added in recent Graphite2 commits and try
> to retrofit those into silgraphite.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

--
--------------------------------------------
MzK

"Time spent with cats is never wasted."
                   -- Sigmund Freud

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Don Lewis-2
On 28 Mar, Kay Schenk wrote:

>
>
> On 03/27/2016 03:37 PM, Don Lewis wrote:
>> On 27 Mar, Andrea Pescetti wrote:
>>> On 29/01/2016 Andrea Pescetti wrote:
>>>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>>>> Release Manager for 4.2.0 since I'm finding that in this period I can
>>>> help more productively with tasks that do not require constant
>>>> interaction ...
>>>> I am surely available to have a significant role in the 4.2.0 release
>>>
>>> A few days after writing this, almost 2 months ago, sudden events left
>>> me incapacitated to make any significant contributions until very
>>> recently. I'm still unable to make long-term commitments.
>>>
>>> Anyway, there are some issues we need to get done as a team before
>>> appointing a release manager makes sense:
>>>
>>> 1) Enough code. Done. The merge of the recent gbuild work totally
>>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
>>> fraction of the fixes that (at that time) were available on trunk. So
>>> here we are already OK, and we've been OK for months.
>>
>> Some of the external software that is bundled has security issues.  I
>> put together a patch for nss here:
>> <https://bz.apache.org/ooo/show_bug.cgi?id=126891>.
>>
>> The version of libxml currently bundled also has a lot of known
>> vulnerabilities.  I'm currently testing a patch.
>>
>> These both need review and testing.
>
> Ok, I'll keep my eyes open for the libxml patch and test
> with your already supplied nss patch.

I filed a PR with the libxml patch late yesterday:
<https://bz.apache.org/ooo/show_bug.cgi?id=126893>

As an added bonus, here is the curl patch:
<https://bz.apache.org/ooo/show_bug.cgi?id=126896>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Release Manager for 4.2.0?

Dennis E. Hamilton
In reply to this post by Don Lewis-2


> -----Original Message-----
> From: Don Lewis [mailto:[hidden email]]
> Sent: Monday, March 28, 2016 15:32
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: Release Manager for 4.2.0?
>
> On 28 Mar, Dennis E. Hamilton wrote:
> > Commenting just on document signing ...
> >
> >> -----Original Message-----
> >> From: Pedro Giffuni [mailto:[hidden email]]
> >> Sent: Monday, March 28, 2016 13:48
> >> To: OOo Apache <[hidden email]>
> >> Subject: Re: Release Manager for 4.2.0?
> > [ ... ]
> >>
> >> [ ... ] I am unsure about what in OpenOffice
> >> uses the new cyphers. I think OpenSSL is used for signing documents:
> >> when we update OpenSSL will AOO automatically accept more signing
> >> options? I would expect browsers will bring their own SSL
> >> implementations.
> > [orcmid]
> >
> > The document signature support in Apache OpenOffice is based on XML
> > Digital Signatures Second Edition,
> > <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>. This has
> > nothing to do with communications via secure sockets of course.
> > Granted that OpenSSL provides library functions for more than that,
> > there is still very limited use for signing documents.
> >
> > X.509 digital certificates are employed.  XadES extensions may be used
> > (impacting metadata information mainly and only implemented by
> > Microsoft in ODF as far as I know).  Depending on the platform the
> > operating-system secure store for the signing key will usually be
> > employed, so there is operating-system integration.  (This is
> > definitely true for Windows.)
>
> OpenSSL also provides libcrypto which contains functions for creating,
> validating, and using certificates.  It uses some of this functionality
> to verify that a secure socket connection is actually connected to the
> desired remote endpoint.  I've used to the openssl command line tool to
> produce a certificate that was used to authenticate a connection from a
> local application to a remote service.
>
> There seems to be a standard place to store certificates under a user's
> home directory in the *nix world.  A while back I signed up for a
> service that requires updates from me to be signed with a certificate
> that they created for me and that my browser downloaded and stashed away
> somewhere.  When I tried signing a document with OpenOffice, it found
> this certificate and offered it as a choice for signing.
>
> Since OpenOffice also uses curl, which is used for downloading files,
> and curl uses OpenSSL, it looks like OpenOffice depends on OpenSSL for
> secure downloads.  I don't know if it downloads anything other than
> extensions and updates.
[orcmid]

That's useful to know.

Apache OpenOffice doesn't generate any client-side certificates, but it does use certs it can find for signing documents.  

I suspect, for secure downloads, AOO only works with the cert from the server, HTTPS-style.
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Damjan Jovanovic
In reply to this post by Don Lewis-2
On Mon, Mar 28, 2016 at 10:59 PM, Don Lewis <[hidden email]> wrote:

> On 28 Mar, Pedro Giffuni wrote:
>> Hi Don;
>>
>>> On 28 Mar, Pedro Giffuni wrote:
>>> > In reply to Don,
>>>
>>> >> The versions of openssl and curl badly need updating for the same
>>> >> reason, and there is one CVE for serf.
>>> >
>>> > FreeBSD casually keeps some backported updates for the same openssl
>>> > version AOO uses:
>>> >
>>> > https://svnweb.freebsd.org/base/stable/9/crypto/openssl/?view=log
>>> >
>>> > It should be pretty straightforward to take them from there and use
>>> them
>>> > into
>>> > main/openssl with minor adaptions.
>>>
>>> That would fix only part of the problem.  The other part of the problem
>>> is that the version of openssl that we currently bundle doesn't
>>> implement the newer and more secure protocols and ciphers.  The older
>>> and less secure ones are gradually getting disabled on the server side.
>>>
>>> For instance, my only copy of Windows is XP, and the last version of IE
>>> released for XP can no longer connect to some web sites because they
>>> have disabled all of the protocols that IE supports.
>>>
>>
>> That is a valid concern, however I am unsure about what in OpenOffice
>> uses the new cyphers. I think OpenSSL is used for signing documents:
>> when we update OpenSSL will AOO automatically accept more signing
>> options? I would expect browsers will bring their own SSL
>> implementations.
>
> I don't know what OpenOffice uses it for, either, but I would expect
> that it also gets used for downloading extensions.  I hadn't even
> thought about signatures.  That's something I haven't exercised it at
> all.

Let's rather research where AOO uses openssl instead of guessing.

I find the use of openssl for document encryption and signing highly
unlikely, as NSS was used there to make use of Firefox's root CA
certificates, and allow configuring personal digital signatures using
the Firefox GUI.

So which modules use openssl?

$ grep openssl */prj/build.lst
oox/prj/build.lst:oox    oox : vos cppu cppuhelper comphelper sal
offapi sax basegfx xmlscript tools vcl BOOST:boost OPENSSL:openssl
LIBXSLT:libxslt NULL
openssl/prj/build.lst:ssl      openssl  :  soltools external EXPAT:expat NULL
openssl/prj/build.lst:ssl      openssl     usr1           -       all
   ssl_mkout NULL
openssl/prj/build.lst:ssl      openssl     nmake          -       all
   ssl_openssl NULL
python/prj/build.lst:py    python    :    SO:so_prereq solenv
OPENSSL:openssl NULL
redland/prj/build.lst:rld     redland : stlport soltools
LIBXML2:libxml2 LIBXSLT:libxslt OPENSSL:openssl NULL
ucb/prj/build.lst:uc ucb : cppuhelper CURL:curl OPENSSL:openssl
LIBXML2:libxml2 LIBXSLT:libxslt offapi sal salhelper ucbhelper udkapi
comphelper SERF:serf tools NULL

Eliminating the openssl module itself from the above results, we have
dependencies to it in oox, python, redland, and ucb.

Oox (used for OOXML, not ODF) uses it in the short
lclCheckEncryptionData() function to detect encryption. It uses it
exclusively for AES crypto.

Python could use it for just about anything, but we don't care because
Python is itself optional.

Redland is an RDF library. It is used by unoxml. Not sure for what.

Ucb apparently uses it for webdav. It doesn't call openssl APIs, but
links to openssl because it uses serf.

Serf needs openssl and is only used by ucb.

Damjan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Release Manager for 4.2.0?

Dennis E. Hamilton


> -----Original Message-----
> From: Damjan Jovanovic [mailto:[hidden email]]
> Sent: Tuesday, March 29, 2016 02:30
> To: Apache OO <[hidden email]>
> Subject: Re: Release Manager for 4.2.0?
[ ... ]
>
> Let's rather research where AOO uses openssl instead of guessing.
>
> I find the use of openssl for document encryption and signing highly
> unlikely, as NSS was used there to make use of Firefox's root CA
> certificates, and allow configuring personal digital signatures using
> the Firefox GUI.
[orcmid]

I am confident that is not the case for Windows, where the OS certificate store is used for private keys and for managing them, such as choosing their email usage.  Whether an NSS library is in the path in any manner is unclear.  I operate on configurations that do not have Firefox installed.

>
> So which modules use openssl?
>
> $ grep openssl */prj/build.lst
> oox/prj/build.lst:oox    oox : vos cppu cppuhelper comphelper sal
> offapi sax basegfx xmlscript tools vcl BOOST:boost OPENSSL:openssl
> LIBXSLT:libxslt NULL
> openssl/prj/build.lst:ssl      openssl  :  soltools external EXPAT:expat
> NULL
> openssl/prj/build.lst:ssl      openssl     usr1           -       all
>    ssl_mkout NULL
> openssl/prj/build.lst:ssl      openssl     nmake          -       all
>    ssl_openssl NULL
> python/prj/build.lst:py    python    :    SO:so_prereq solenv
> OPENSSL:openssl NULL
> redland/prj/build.lst:rld     redland : stlport soltools
> LIBXML2:libxml2 LIBXSLT:libxslt OPENSSL:openssl NULL
> ucb/prj/build.lst:uc ucb : cppuhelper CURL:curl OPENSSL:openssl
> LIBXML2:libxml2 LIBXSLT:libxslt offapi sal salhelper ucbhelper udkapi
> comphelper SERF:serf tools NULL
>
> Eliminating the openssl module itself from the above results, we have
> dependencies to it in oox, python, redland, and ucb.
>
> Oox (used for OOXML, not ODF) uses it in the short
> lclCheckEncryptionData() function to detect encryption. It uses it
> exclusively for AES crypto.
>
> Python could use it for just about anything, but we don't care because
> Python is itself optional.
>
> Redland is an RDF library. It is used by unoxml. Not sure for what.
[orcmid]

There are some manifest.rdf files included as boilerplate in ODF 1.2 packages.  They are produced automatically.  I don't think they are consumed in any manner, but they might be parsed anyhow [;<).  They are included in signed packages and they are encrypted in encrypted packages.  They have no dependency in the ODF specification.  So far, they are there for mining of document metadata by external products.

PS: Handling of external entities in XML files can lead to use of internet transport.  Not certain what the use case might be.  It is not something that would be done with AOO-created XML inside ODF.

PPS: The access to external components from within ODF documents can involve Internet transport.  Won't this exercise the dependency from CURL that Don Lewis mentions?

>
> Ucb apparently uses it for webdav. It doesn't call openssl APIs, but
> links to openssl because it uses serf.
[orcmid]

WebDAV servers can require negotiation of HTTP authentication.  That may be the reason for this.  WebDAV protocol is atop HTTP.

>
> Serf needs openssl and is only used by ucb.
>
> Damjan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

FR web forum
In reply to this post by Andrea Pescetti-2
Hello all,
Any news for this next 4.2.0?

----- Mail original -----
De: "Andrea Pescetti" <[hidden email]>
À: [hidden email]
Envoyé: Dimanche 27 Mars 2016 22:13:11
Objet: Re: Release Manager for 4.2.0?

On 29/01/2016 Andrea Pescetti wrote:
> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> Release Manager for 4.2.0 since I'm finding that in this period I can
> help more productively with tasks that do not require constant
> interaction ...
> I am surely available to have a significant role in the 4.2.0 release

A few days after writing this, almost 2 months ago, sudden events left
me incapacitated to make any significant contributions until very
recently. I'm still unable to make long-term commitments.

Anyway, there are some issues we need to get done as a team before
appointing a release manager makes sense:

1) Enough code. Done. The merge of the recent gbuild work totally
justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
fraction of the fixes that (at that time) were available on trunk. So
here we are already OK, and we've been OK for months.

2) Localization. I got shell access to the Pootle server a few days ago.
I'm still looking around, and if someone else want to join this is an
important part. We need to have a solid process for updating
translations (the full route: new strings in code -> Pootle -> back to
code -> in localized builds) in place.

3) Buildbots and ASF-owned build machines. Buildbots are not essential
for a release: 4.1.2 was built (like all previous releases in history)
on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
can't use buildbots for it; we need to setup new systems. Those who read
the infrastructure@ list can see the discussion I started there
yesterday. Still, having buildbots helps QA and having ASF-owned build
machines is an important investment for the project: at that point we
will be able to make a release within days, not months. We should make
as much progress as we can here. Again, if anybody can help, this is an
important area.

4) There are several optimizations I have in mind, especially on
reducing a bit our binary size on Linux (trust me, it is really a pain
to commit all those binaries to SVN, or to any version control system).
But they are not essential.

I have just committed to the devtools/ area the scripts we (mainly
Juergen) used to build the 4.1.2 release, with specs of the build
machines. I've had them since last October, but I never committed them.
They are a first step if we want to build our release binaries on ASF
hardware: they contain build options and config.log to have some more
information on the environment.

My next priorities will be localization (especially, re-exporting the
Italian translation to Pootle and re-importing it) and and a
proof-of-concept VM for building releases on Linux (64 bit) based on the
above scripts. There is plenty of room for other to jump in (Linux 32,
Windows, Mac; or localization management) so please do!

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Kay Schenk-2
In reply to this post by Andrea Pescetti-2
[getting back to this .. see below]

On 03/27/2016 01:13 PM, Andrea Pescetti wrote:

> On 29/01/2016 Andrea Pescetti wrote:
>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>> Release Manager for 4.2.0 since I'm finding that in this period I can
>> help more productively with tasks that do not require constant
>> interaction ...
>> I am surely available to have a significant role in the 4.2.0 release
>
> A few days after writing this, almost 2 months ago, sudden events left
> me incapacitated to make any significant contributions until very
> recently. I'm still unable to make long-term commitments.
>
> Anyway, there are some issues we need to get done as a team before
> appointing a release manager makes sense:
>
> 1) Enough code. Done. The merge of the recent gbuild work totally
> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> fraction of the fixes that (at that time) were available on trunk. So
> here we are already OK, and we've been OK for months.
>
> 2) Localization. I got shell access to the Pootle server a few days ago.
> I'm still looking around, and if someone else want to join this is an
> important part. We need to have a solid process for updating
> translations (the full route: new strings in code -> Pootle -> back to
> code -> in localized builds) in place.

As the localization changes are quite significant from 4.1.2 to 4.2.0,
can you give us an update on the porting process?  Are there
instructions, etc?

>
> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
> for a release: 4.1.2 was built (like all previous releases in history)
> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
> can't use buildbots for it; we need to setup new systems. Those who read
> the infrastructure@ list can see the discussion I started there
> yesterday. Still, having buildbots helps QA and having ASF-owned build
> machines is an important investment for the project: at that point we
> will be able to make a release within days, not months. We should make
> as much progress as we can here. Again, if anybody can help, this is an
> important area.

On this. Why can't we use the buildbot assuming we can get all of them
working satisfactorily? I know there are, for example, some library
upgrades/differences between the buildbots and what we've used in the
past, but if we're upgrading to a new version, why can't we just spec
this in the system requirements for 4.2.0?
Can we flesh out specs in this direction? New versions of software often
dictate system software changes.

>
> 4) There are several optimizations I have in mind, especially on
> reducing a bit our binary size on Linux (trust me, it is really a pain
> to commit all those binaries to SVN, or to any version control system).
> But they are not essential.
>
> I have just committed to the devtools/ area the scripts we (mainly
> Juergen) used to build the 4.1.2 release, with specs of the build
> machines. I've had them since last October, but I never committed them.
> They are a first step if we want to build our release binaries on ASF
> hardware: they contain build options and config.log to have some more
> information on the environment.

OK, we will take an indepth look at this, but I really feel we should
move on from specialized release build hardware.

>
> My next priorities will be localization (especially, re-exporting the
> Italian translation to Pootle and re-importing it) and and a
> proof-of-concept VM for building releases on Linux (64 bit) based on the
> above scripts. There is plenty of room for other to jump in (Linux 32,
> Windows, Mac; or localization management) so please do!
>
> Regards,
>    Andrea.

Thanks for all this!



--
--------------------------------------------
MzK

"Time spent with cats is never wasted."
                    -- Sigmund Freud

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Release Manager for 4.2.0?

Dennis E. Hamilton


> -----Original Message-----
> From: Kay Schenk [mailto:[hidden email]]
> Sent: Thursday, June 16, 2016 09:55
> To: [hidden email]
> Subject: Re: Release Manager for 4.2.0?
>
> [getting back to this .. see below]
>
> On 03/27/2016 01:13 PM, Andrea Pescetti wrote:
> > On 29/01/2016 Andrea Pescetti wrote:
> >> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
> >> Release Manager for 4.2.0 since I'm finding that in this period I can
> >> help more productively with tasks that do not require constant
> >> interaction ...
> >> I am surely available to have a significant role in the 4.2.0 release
> >
> > A few days after writing this, almost 2 months ago, sudden events left
> > me incapacitated to make any significant contributions until very
> > recently. I'm still unable to make long-term commitments.
> >
> > Anyway, there are some issues we need to get done as a team before
> > appointing a release manager makes sense:
> >
> > 1) Enough code. Done. The merge of the recent gbuild work totally
> > justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
> > fraction of the fixes that (at that time) were available on trunk. So
> > here we are already OK, and we've been OK for months.
[orcmid]

I am unclear about the state of the gbuild merge.  Was it done even though there are unresolved problems using it for building Windows binaries?

[ ... ]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Kay Schenk-2


On 06/16/2016 11:28 AM, Dennis E. Hamilton wrote:

>
>
>> -----Original Message-----
>> From: Kay Schenk [mailto:[hidden email]]
>> Sent: Thursday, June 16, 2016 09:55
>> To: [hidden email]
>> Subject: Re: Release Manager for 4.2.0?
>>
>> [getting back to this .. see below]
>>
>> On 03/27/2016 01:13 PM, Andrea Pescetti wrote:
>>> On 29/01/2016 Andrea Pescetti wrote:
>>>> For 4.2.0 we need a Release Manager. I would prefer NOT to be the
>>>> Release Manager for 4.2.0 since I'm finding that in this period I can
>>>> help more productively with tasks that do not require constant
>>>> interaction ...
>>>> I am surely available to have a significant role in the 4.2.0 release
>>>
>>> A few days after writing this, almost 2 months ago, sudden events left
>>> me incapacitated to make any significant contributions until very
>>> recently. I'm still unable to make long-term commitments.
>>>
>>> Anyway, there are some issues we need to get done as a team before
>>> appointing a release manager makes sense:
>>>
>>> 1) Enough code. Done. The merge of the recent gbuild work totally
>>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
>>> fraction of the fixes that (at that time) were available on trunk. So
>>> here we are already OK, and we've been OK for months.
> [orcmid]
>
> I am unclear about the state of the gbuild merge.  Was it done even though there are unresolved problems using it for building Windows binaries?

no, it was not...hopefully soon or ???? I need to test this out myself
on my Linux-32 box.

>
> [ ... ]
>


--
--------------------------------------------
MzK

"Time spent with cats is never wasted."
                    -- Sigmund Freud

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Release Manager for 4.2.0?

Andrea Pescetti-2
In reply to this post by Kay Schenk-2
On 16/06/2016 Kay Schenk wrote:

> On 03/27/2016 01:13 PM, Andrea Pescetti wrote:
>> Anyway, there are some issues we need to get done as a team ...before
>> appointing a release manager makes sense:
>>
>> 1) Enough code. Done. The merge of the recent gbuild work totally
>> justifies a 4.2.0 release. Also, in 4.1.2 we only included a tiny
>> fraction of the fixes that (at that time) were available on trunk. So
>> here we are already OK, and we've been OK for months.
>>
>> 2) Localization. I got shell access to the Pootle server a few days ago.
>> I'm still looking around, and if someone else want to join this is an
>> important part. We need to have a solid process for updating
>> translations (the full route: new strings in code -> Pootle -> back to
>> code -> in localized builds) in place.
>
> As the localization changes are quite significant from 4.1.2 to 4.2.0,
> can you give us an update on the porting process?  Are there
> instructions, etc?

I haven't been able to check all of this yet, sorry. But Infra provided
full access in the meantime, meaning that the bottleneck here is only on
our side and not on the Infra side.

>> 3) Buildbots and ASF-owned build machines. Buildbots are not essential
>> for a release: 4.1.2 was built (like all previous releases in history)
>> on non-ASF hardware; even if we build 4.2.0 on ASF-owned hardware, we
>> can't use buildbots for it; we need to setup new systems. ...
> On this. Why can't we use the buildbot assuming we can get all of them
> working satisfactorily? I know there are, for example, some library
> upgrades/differences between the buildbots and what we've used in the
> past, but if we're upgrading to a new version, why can't we just spec
> this in the system requirements for 4.2.0?

We have a "baseline", minimal system requirements that are supposed to
be valid for all the 4.x releases. We build releases on old (but still
supported) system to guarantee maximum compatibility for users. No ASF
buildbots match our baseline (they are all more advanced).
Unfortunately, the discussion on this got stalled on the Infra list when
Infra wrote it would be very problematic for them to create VMs for us
matching our specifications - they decided to focus on only one, recent,
Linux-based distribution for their Linux VMs. There might be solutions
involving Docker, but this only makes things more complex.

> Can we flesh out specs in this direction? New versions of software often
> dictate system software changes.

The major difference would be, I think, in the required glibc version
for Linux builds.

> I really feel we should
> move on from specialized release build hardware.

It is not specialized hardware in itself, it is a fairly ordinary system
that is "specialized" since it is only available to one person. The best
thing would be to get the same system moved to ASF-owned VMs, accessible
to all PMC members who want to do so. At present, the discussion with
Infra is stalled as explained above.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12
Loading...