You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2016/08/05 16:28:15 UTC
[PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Thursday, August 4, 2016 15:52
> To: dev@openoffice.apache.org
> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>
> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
[ ... ]
> >
> > hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
> >
> > Should we get started on these?
>
> it depends what we want that they should contain. The ZIP file for
> Windows contains a LICENSE and NOTICE file as well as an ASC file for
> the DLL. As it is only a patch IMHO we don't need to provide another
> LICENSE and NOTICE file which is already available in the OpenOffice
> installation. Also the ASC is not necessary as we provide it already
> (together with MD5 and SHA256) for the whole ZIP file.
[orcmid]
I think there is a misunderstanding. Two matters:
1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>
> That means that only the README and library file remains.
>
> When the README for Windows keep its length then I don't want to copy
> this on the dowload webpage. ;-)
>
> So, when we put the README for all platforms in their ZIP files then we
> can just put a pointer to it on the download webpage and thats it.
[orcmid]
Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>
> To cut a long story short:
> I would say yes for a ZIP file for every platform.
[ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/06/2016 02:41 AM, schrieb Dennis E. Hamilton:
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Friday, August 5, 2016 10:47
>> To: dev@openoffice.apache.org
>> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
>> Applying openoffice-4.1.2-patch1 for Windows)
>>
>> Am 08/05/2016 06:28 PM, schrieb Dennis E. Hamilton:
> [ ... ]
>>>>
>>>> So, when we put the README for all platforms in their ZIP files then
>> we
>>>> can just put a pointer to it on the download webpage and thats it.
>>> [orcmid]
>>>
>>> Yes, that seems like a fine idea. The README can be linked the same
>> way the .md5, .sha256, and .asc are linked.
>>
>> Ahm, no. ;-) As the README is *inside* the ZIP file I cannot provide a
>> direct link to it. But a little text hint should do the job.
> [orcmid]
>
> That's why I put one copy outside and one inside that travels with the Zip. The one outside can be linked to just like any of the other companion text files, and it can be accessed without downloading the archive file.
ah, yes, then we can link it. ;-) I thought it be just a single zip file
per platform.
Marcus
>>> Also, the README may become simpler if we can link to some of the
>> information and not have so much detail in the README text itself. It
>> might even be useful to have an .html README for that matter. But that
>> is all extra. Right now I think we want to get into the testing and see
>> how to smooth what we have.
>>>
>>> PS: A friend of mine is looking into the MacOSX situation. He points
>> out that one can use the Finder to do the job without users having to
>> use Terminal sessions. I don't have further information at this time.
>>
>> Great, I thought this already and provided this in the (very short)
>> version of the README that Kay has already committed aside the MacOSX
>> patch.
>>
>> Please, can you ask your friend to have a look if it's OK and
>> sufficient? If not, please ask for some more details. Thanks!
> [orcmid]
>
> I have already pointed him to what we have in the MacOSX folder.
>
>>
>>> PPS: The inclusion of scripts that do the job is also worthy of
>> consideration, perhaps making it unnecessary to build executables. I
>> will be looking at finding a .bat file that works safely for the Windows
>> case. That can make the instructions much shorter :).
>>
>> Yes, a script would be a great help to our Windows users. Unfortunately,
>> I've no knowledge about how to do this scripting on Windows.
>>
>>>> To cut a long story short:
>>>> I would say yes for a ZIP file for every platform.
>>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Friday, August 5, 2016 10:47
> To: dev@openoffice.apache.org
> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
> Applying openoffice-4.1.2-patch1 for Windows)
>
> Am 08/05/2016 06:28 PM, schrieb Dennis E. Hamilton:
[ ... ]
> >>
> >> So, when we put the README for all platforms in their ZIP files then
> we
> >> can just put a pointer to it on the download webpage and thats it.
> > [orcmid]
> >
> > Yes, that seems like a fine idea. The README can be linked the same
> way the .md5, .sha256, and .asc are linked.
>
> Ahm, no. ;-) As the README is *inside* the ZIP file I cannot provide a
> direct link to it. But a little text hint should do the job.
[orcmid]
That's why I put one copy outside and one inside that travels with the Zip. The one outside can be linked to just like any of the other companion text files, and it can be accessed without downloading the archive file.
- Dennis
>
> > Also, the README may become simpler if we can link to some of the
> information and not have so much detail in the README text itself. It
> might even be useful to have an .html README for that matter. But that
> is all extra. Right now I think we want to get into the testing and see
> how to smooth what we have.
> >
> > PS: A friend of mine is looking into the MacOSX situation. He points
> out that one can use the Finder to do the job without users having to
> use Terminal sessions. I don't have further information at this time.
>
> Great, I thought this already and provided this in the (very short)
> version of the README that Kay has already committed aside the MacOSX
> patch.
>
> Please, can you ask your friend to have a look if it's OK and
> sufficient? If not, please ask for some more details. Thanks!
[orcmid]
I have already pointed him to what we have in the MacOSX folder.
>
> > PPS: The inclusion of scripts that do the job is also worthy of
> consideration, perhaps making it unnecessary to build executables. I
> will be looking at finding a .bat file that works safely for the Windows
> case. That can make the instructions much shorter :).
>
> Yes, a script would be a great help to our Windows users. Unfortunately,
> I've no knowledge about how to do this scripting on Windows.
>
> >> To cut a long story short:
> >> I would say yes for a ZIP file for every platform.
> > [ ... ]
>
> Marcus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/05/2016 06:28 PM, schrieb Dennis E. Hamilton:
> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Thursday, August 4, 2016 15:52
>> To: dev@openoffice.apache.org
>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>
>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
> [ ... ]
>>>
>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>
>>> Should we get started on these?
>>
>> it depends what we want that they should contain. The ZIP file for
>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>> the DLL. As it is only a patch IMHO we don't need to provide another
>> LICENSE and NOTICE file which is already available in the OpenOffice
>> installation. Also the ASC is not necessary as we provide it already
>> (together with MD5 and SHA256) for the whole ZIP file.
> [orcmid]
>
> I think there is a misunderstanding. Two matters:
>
> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>
> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>
> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
sure, the text files are harmless (and small enough!) to provide them. I
just thought that they are not really necessary. But when it's an
requirement, then OK. And the additional ASC is an additional step of
security verification. Also OK.
>> That means that only the README and library file remains.
>>
>> When the README for Windows keep its length then I don't want to copy
>> this on the dowload webpage. ;-)
>>
>> So, when we put the README for all platforms in their ZIP files then we
>> can just put a pointer to it on the download webpage and thats it.
> [orcmid]
>
> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
Ahm, no. ;-) As the README is *inside* the ZIP file I cannot provide a
direct link to it. But a little text hint should do the job.
> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>
> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
Great, I thought this already and provided this in the (very short)
version of the README that Kay has already committed aside the MacOSX patch.
Please, can you ask your friend to have a look if it's OK and
sufficient? If not, please ask for some more details. Thanks!
> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
Yes, a script would be a great help to our Windows users. Unfortunately,
I've no knowledge about how to do this scripting on Windows.
>> To cut a long story short:
>> I would say yes for a ZIP file for every platform.
> [ ... ]
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Carl Marcum <cm...@apache.org>.
On 08/10/2016 03:09 AM, Jan H�ydahl wrote:
>> 9. aug. 2016 kl. 13.23 skrev Carl Marcum <cm...@apache.org>:
>> ...
>> Could we use a cross-platform installer like izpack [1]?
>>
>> I started trying it out last weekend and it looks like it could do the job of running a rename script and copying in the library.
>
> I previously used izPack for cross platform install of a Tomcat application.
> You can develop custom plugins for izPack as well as custom scripts, so creating something which looks for AOO in a number
> of predefined locations, and also validates the correct version dependency, would probably be within reach as well.
> I think you can tell izPack to do actions with elevated privileges.
>
> I also tested generating a Windows-executable wrapper using Launch4J (http://launch4j.sourceforge.net/ <http://launch4j.sourceforge.net/>), and it worked well.
> The resulting exe file is self contained, will auto-resolve any installed JRE on the system, or display a popup with
> Java download link if it cannot find Java on the system. Launch4J can also generate executable wrappers for macOS but
> I did not try that. Both izPack and launch4j can be built from e.g. an Ant build script.
>
> --
> Jan H�ydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
Hi Jan,
That's good information. I hadn't seen launch4j before.
Even though we probably won't use an installer for this case, I have
other uses for launch4j.
Thanks for the tip !
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Jan Høydahl <ja...@cominvent.com>.
> 9. aug. 2016 kl. 13.23 skrev Carl Marcum <cm...@apache.org>:
> ...
> Could we use a cross-platform installer like izpack [1]?
>
> I started trying it out last weekend and it looks like it could do the job of running a rename script and copying in the library.
I previously used izPack for cross platform install of a Tomcat application.
You can develop custom plugins for izPack as well as custom scripts, so creating something which looks for AOO in a number
of predefined locations, and also validates the correct version dependency, would probably be within reach as well.
I think you can tell izPack to do actions with elevated privileges.
I also tested generating a Windows-executable wrapper using Launch4J (http://launch4j.sourceforge.net/ <http://launch4j.sourceforge.net/>), and it worked well.
The resulting exe file is self contained, will auto-resolve any installed JRE on the system, or display a popup with
Java download link if it cannot find Java on the system. Launch4J can also generate executable wrappers for macOS but
I did not try that. Both izPack and launch4j can be built from e.g. an Ant build script.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/9/2016 8:29 AM, Dennis E. Hamilton wrote:
...
> [orcmid]
>
> I think requiring Java is a deal breaker, especially on Windows where
> it is not installed by default. If we required Java for AOO, that
> would be different, but we don't do that and we don't do anything to
> automate the user having the right Java bitness for AOO in the
> Windows case.
I think we need to distinguish between "requiring Java" and "requiring
Java that will work with AOO"
I have had Java installed on my home systems since soon after it was
publicly released. I still had to do a Java install for AOO.
I suspect the installer only requires Java, which is a much weaker
requirement, met by a lot more Windows computers, than requiring a
32-bit Java.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Carl Marcum [mailto:cmarcum@apache.org]
> Sent: Tuesday, August 9, 2016 04:23
> To: dev@openoffice.apache.org
> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
> Applying openoffice-4.1.2-patch1 for Windows)
>
> On 08/05/2016 12:28 PM, Dennis E. Hamilton wrote:
> > Branching off the part that is not about the Windows 4.1.2-patch1
> [TESTING].
> >
> >> -----Original Message-----
> >> From: Marcus [mailto:marcus.mail@wtnet.de]
> >> Sent: Thursday, August 4, 2016 15:52
> >> To: dev@openoffice.apache.org
> >> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
[ ... ]
> >> To cut a long story short:
> >> I would say yes for a ZIP file for every platform.
> > [ ... ]
> >
> >
>
> Could we use a cross-platform installer like izpack [1]?
>
> I started trying it out last weekend and it looks like it could do the
> job of running a rename script and copying in the library.
>
> A few notes.
>
> It can:
> display a readme to explain what will happen.
> display our license for acceptance.
> run a script depending on platform.
> Copy in files based on platform.
>
> Requires Java on the machine to run installer.
> Also the user need to be able to use a file chooser to find the AOO
> directory.
[orcmid]
I think requiring Java is a deal breaker, especially on Windows where it is not installed by default. If we required Java for AOO, that would be different, but we don't do that and we don't do anything to automate the user having the right Java bitness for AOO in the Windows case.
Explaining how to find the AOO directory is half the problem. Elevating privileges is the other. The third half is the easy-to-automate part although we need to provide something that can be found easily that reflects the version of AOO installed. This is something that we need to fix in future releases. (I think izpack should also handle finding the AOO directory and privilege elevation. It may be overkill though, although registry access might be useful.)
I have a batch script for Windows being unit tested. There is also the prospect of a self-extracting/-executing Zip on Windows. (The batch script can be "Run as Administrator" so users can minimize the pain of privilege elevation and this will show immediately if they are unable to provide administrator credentials.
>
> If so I will continue to pursue this but may need so help with the
> scripts and testing.
[orcmid]
I can probably help with testing but can't invest much into izpack-ness. Also, I am on Java 8 on my machines that have Java at the moment.
>
> [1] http://izpack.org/
>
> Thanks,
> Carl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Carl Marcum <cm...@apache.org>.
On 08/05/2016 12:28 PM, Dennis E. Hamilton wrote:
> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Thursday, August 4, 2016 15:52
>> To: dev@openoffice.apache.org
>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>
>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
> [ ... ]
>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>
>>> Should we get started on these?
>> it depends what we want that they should contain. The ZIP file for
>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>> the DLL. As it is only a patch IMHO we don't need to provide another
>> LICENSE and NOTICE file which is already available in the OpenOffice
>> installation. Also the ASC is not necessary as we provide it already
>> (together with MD5 and SHA256) for the whole ZIP file.
> [orcmid]
>
> I think there is a misunderstanding. Two matters:
>
> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>
> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>
> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>> That means that only the README and library file remains.
>>
>> When the README for Windows keep its length then I don't want to copy
>> this on the dowload webpage. ;-)
>>
>> So, when we put the README for all platforms in their ZIP files then we
>> can just put a pointer to it on the download webpage and thats it.
> [orcmid]
>
> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
>
> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>
> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
>
> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>
>> To cut a long story short:
>> I would say yes for a ZIP file for every platform.
> [ ... ]
>
>
Could we use a cross-platform installer like izpack [1]?
I started trying it out last weekend and it looks like it could do the
job of running a rename script and copying in the library.
A few notes.
It can:
display a readme to explain what will happen.
display our license for acceptance.
run a script depending on platform.
Copy in files based on platform.
Requires Java on the machine to run installer.
Also the user need to be able to use a file chooser to find the AOO
directory.
If so I will continue to pursue this but may need so help with the
scripts and testing.
[1] http://izpack.org/
Thanks,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/05/2016 07:02 PM, schrieb Dennis E. Hamilton:
>
>
>> -----Original Message-----
>> From: Kay Schenk [mailto:kay.schenk@gmail.com]
>> Sent: Friday, August 5, 2016 09:36
>> To: OOo Apache<de...@openoffice.apache.org>; Dennis Hamilton
>> <de...@acm.org>
>> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
>> Applying openoffice-4.1.2-patch1 for Windows)
>>
>> On Fri, Aug 5, 2016 at 9:28 AM, Dennis E. Hamilton
>> <de...@acm.org>
>> wrote:
>>
>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>> [TESTING].
>>>
>>>> -----Original Message-----
>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>> Sent: Thursday, August 4, 2016 15:52
>>>> To: dev@openoffice.apache.org
>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>
>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>> [ ... ]
>>>>>
>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>
>>>>> Should we get started on these?
>>>>
>>>> it depends what we want that they should contain. The ZIP file for
>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file
>> for
>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>> installation. Also the ASC is not necessary as we provide it already
>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>> [orcmid]
>>>
>>> I think there is a misunderstanding. Two matters:
>>>
>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
>>> practice is to include NOTICE as well on binary distributions. The
>> patch
>>> qualifies, especially when it is moved to general distribution. It is
>> also
>>> easy and harmless to provide.
>>>
>>> 2. The reason for preserving the .asc on the shared-library binary is
>>> because it authenticates with respect to who produced it and
>> establishes
>>> that it has not been modified as supplied in the package (or as the
>> result
>>> of some glitch in creation of the Zip). It provides a level of
>>> accountability and, also, auditability.
>>>
>>> Even though few people will check all of these, they remain possible
>> to be
>>> checked. Since this is a matter of security vulnerabilities and
>> involves
>>> elevation of privilege to perform, I believe it is important to
>> demonstrate
>>> diligence and care, so that users have confidence in this procedure to
>> the
>>> extent they are comfortable. Also, if it becomes necessary to
>> troubleshoot
>>> a problem with these patch applications, we have the means to
>> authenticate
>>> what they are using to ensure there are no counterfeits being offered
>> to
>>> users.
>>>>
>>>> That means that only the README and library file remains.
>>>>
>>>> When the README for Windows keep its length then I don't want to
>> copy
>>>> this on the dowload webpage. ;-)
>>>>
>>>> So, when we put the README for all platforms in their ZIP files then
>> we
>>>> can just put a pointer to it on the download webpage and thats it.
>>> [orcmid]
>>>
>>> Yes, that seems like a fine idea. The README can be linked the same
>> way
>>> the .md5, .sha256, and .asc are linked.
>>>
>>> Also, the README may become simpler if we can link to some of the
>>> information and not have so much detail in the README text itself. It
>>> might even be useful to have an .html README for that matter. But
>> that is
>>> all extra. Right now I think we want to get into the testing and see
>> how
>>> to smooth what we have.
>>>
>>> PS: A friend of mine is looking into the MacOSX situation. He points
>> out
>>> that one can use the Finder to do the job without users having to use
>>> Terminal sessions. I don't have further information at this time.
>>>
>>> PPS: The inclusion of scripts that do the job is also worthy of
>>> consideration, perhaps making it unnecessary to build executables. I
>> will
>>> be looking at finding a .bat file that works safely for the Windows
>> case.
>>> That can make the instructions much shorter :).
>>>
>>
>> \u200b??? I think you'd still need the executables as part of the payload. But
>> batch or script files would make the "installation" easier. We should
>> certainly consider this for future patches.\u200b
> [orcmid]
>
> Yes, for the Windows case the .bat would be inside the Zip along with the other material. It would be extracted along with the other material. But then it can be executed where unzipped by an user running it as administrator in place. So all of the renaming and copying business would be semi-automatic and users operating from non-administrator accounts would only have to authorize administrative operation once (it is to be hoped).
>
> There is a variant that involves what is called a self-extracting Zip (an .exe file) that will run a command after doing so. I don't know whether we want to do that, but it would be a way to create an installer for the patch. That is a potential future step to explore for the Windows case.
>
> One step at a time ...
yes, right. A self-executed Zip with starting the .bat after
uncompressing would be a nice bonus.
Marcus
>> \u200b For this situation, we may as well go with what we've got I think.
>>
>> Linux is very straightforward. I don't know anything about Macs. I do
>> know
>> that the Windows varients complicate things quite a bit.\u200b
>>
>>
>>>>
>>>> To cut a long story short:
>>>> I would say yes for a ZIP file for every platform.
>>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Kay Schenk [mailto:kay.schenk@gmail.com]
> Sent: Friday, August 5, 2016 09:36
> To: OOo Apache <de...@openoffice.apache.org>; Dennis Hamilton
> <de...@acm.org>
> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
> Applying openoffice-4.1.2-patch1 for Windows)
>
> On Fri, Aug 5, 2016 at 9:28 AM, Dennis E. Hamilton
> <de...@acm.org>
> wrote:
>
> > Branching off the part that is not about the Windows 4.1.2-patch1
> > [TESTING].
> >
> > > -----Original Message-----
> > > From: Marcus [mailto:marcus.mail@wtnet.de]
> > > Sent: Thursday, August 4, 2016 15:52
> > > To: dev@openoffice.apache.org
> > > Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> > >
> > > Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
> > [ ... ]
> > > >
> > > > hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
> > > >
> > > > Should we get started on these?
> > >
> > > it depends what we want that they should contain. The ZIP file for
> > > Windows contains a LICENSE and NOTICE file as well as an ASC file
> for
> > > the DLL. As it is only a patch IMHO we don't need to provide another
> > > LICENSE and NOTICE file which is already available in the OpenOffice
> > > installation. Also the ASC is not necessary as we provide it already
> > > (together with MD5 and SHA256) for the whole ZIP file.
> > [orcmid]
> >
> > I think there is a misunderstanding. Two matters:
> >
> > 1. The use of LICENSE is required by the ALv2 itself, and the ASF
> > practice is to include NOTICE as well on binary distributions. The
> patch
> > qualifies, especially when it is moved to general distribution. It is
> also
> > easy and harmless to provide.
> >
> > 2. The reason for preserving the .asc on the shared-library binary is
> > because it authenticates with respect to who produced it and
> establishes
> > that it has not been modified as supplied in the package (or as the
> result
> > of some glitch in creation of the Zip). It provides a level of
> > accountability and, also, auditability.
> >
> > Even though few people will check all of these, they remain possible
> to be
> > checked. Since this is a matter of security vulnerabilities and
> involves
> > elevation of privilege to perform, I believe it is important to
> demonstrate
> > diligence and care, so that users have confidence in this procedure to
> the
> > extent they are comfortable. Also, if it becomes necessary to
> troubleshoot
> > a problem with these patch applications, we have the means to
> authenticate
> > what they are using to ensure there are no counterfeits being offered
> to
> > users.
> > >
> > > That means that only the README and library file remains.
> > >
> > > When the README for Windows keep its length then I don't want to
> copy
> > > this on the dowload webpage. ;-)
> > >
> > > So, when we put the README for all platforms in their ZIP files then
> we
> > > can just put a pointer to it on the download webpage and thats it.
> > [orcmid]
> >
> > Yes, that seems like a fine idea. The README can be linked the same
> way
> > the .md5, .sha256, and .asc are linked.
> >
> > Also, the README may become simpler if we can link to some of the
> > information and not have so much detail in the README text itself. It
> > might even be useful to have an .html README for that matter. But
> that is
> > all extra. Right now I think we want to get into the testing and see
> how
> > to smooth what we have.
> >
> > PS: A friend of mine is looking into the MacOSX situation. He points
> out
> > that one can use the Finder to do the job without users having to use
> > Terminal sessions. I don't have further information at this time.
> >
> > PPS: The inclusion of scripts that do the job is also worthy of
> > consideration, perhaps making it unnecessary to build executables. I
> will
> > be looking at finding a .bat file that works safely for the Windows
> case.
> > That can make the instructions much shorter :).
> >
>
> ??? I think you'd still need the executables as part of the payload. But
> batch or script files would make the "installation" easier. We should
> certainly consider this for future patches.
[orcmid]
Yes, for the Windows case the .bat would be inside the Zip along with the other material. It would be extracted along with the other material. But then it can be executed where unzipped by an user running it as administrator in place. So all of the renaming and copying business would be semi-automatic and users operating from non-administrator accounts would only have to authorize administrative operation once (it is to be hoped).
There is a variant that involves what is called a self-extracting Zip (an .exe file) that will run a command after doing so. I don't know whether we want to do that, but it would be a way to create an installer for the patch. That is a potential future step to explore for the Windows case.
One step at a time ...
>
> For this situation, we may as well go with what we've got I think.
>
> Linux is very straightforward. I don't know anything about Macs. I do
> know
> that the Windows varients complicate things quite a bit.
>
>
> > >
> > > To cut a long story short:
> > > I would say yes for a ZIP file for every platform.
> > [ ... ]
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
>
> --
> ----------------------------------------------------------------------
> MzK
>
> "Time spent with cats is never wasted."
> -- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Aug 5, 2016 at 9:28 AM, Dennis E. Hamilton <de...@acm.org>
wrote:
> Branching off the part that is not about the Windows 4.1.2-patch1
> [TESTING].
>
> > -----Original Message-----
> > From: Marcus [mailto:marcus.mail@wtnet.de]
> > Sent: Thursday, August 4, 2016 15:52
> > To: dev@openoffice.apache.org
> > Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> >
> > Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
> [ ... ]
> > >
> > > hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
> > >
> > > Should we get started on these?
> >
> > it depends what we want that they should contain. The ZIP file for
> > Windows contains a LICENSE and NOTICE file as well as an ASC file for
> > the DLL. As it is only a patch IMHO we don't need to provide another
> > LICENSE and NOTICE file which is already available in the OpenOffice
> > installation. Also the ASC is not necessary as we provide it already
> > (together with MD5 and SHA256) for the whole ZIP file.
> [orcmid]
>
> I think there is a misunderstanding. Two matters:
>
> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
> practice is to include NOTICE as well on binary distributions. The patch
> qualifies, especially when it is moved to general distribution. It is also
> easy and harmless to provide.
>
> 2. The reason for preserving the .asc on the shared-library binary is
> because it authenticates with respect to who produced it and establishes
> that it has not been modified as supplied in the package (or as the result
> of some glitch in creation of the Zip). It provides a level of
> accountability and, also, auditability.
>
> Even though few people will check all of these, they remain possible to be
> checked. Since this is a matter of security vulnerabilities and involves
> elevation of privilege to perform, I believe it is important to demonstrate
> diligence and care, so that users have confidence in this procedure to the
> extent they are comfortable. Also, if it becomes necessary to troubleshoot
> a problem with these patch applications, we have the means to authenticate
> what they are using to ensure there are no counterfeits being offered to
> users.
> >
> > That means that only the README and library file remains.
> >
> > When the README for Windows keep its length then I don't want to copy
> > this on the dowload webpage. ;-)
> >
> > So, when we put the README for all platforms in their ZIP files then we
> > can just put a pointer to it on the download webpage and thats it.
> [orcmid]
>
> Yes, that seems like a fine idea. The README can be linked the same way
> the .md5, .sha256, and .asc are linked.
>
> Also, the README may become simpler if we can link to some of the
> information and not have so much detail in the README text itself. It
> might even be useful to have an .html README for that matter. But that is
> all extra. Right now I think we want to get into the testing and see how
> to smooth what we have.
>
> PS: A friend of mine is looking into the MacOSX situation. He points out
> that one can use the Finder to do the job without users having to use
> Terminal sessions. I don't have further information at this time.
>
> PPS: The inclusion of scripts that do the job is also worthy of
> consideration, perhaps making it unnecessary to build executables. I will
> be looking at finding a .bat file that works safely for the Windows case.
> That can make the instructions much shorter :).
>
??? I think you'd still need the executables as part of the payload. But
batch or script files would make the "installation" easier. We should
certainly consider this for future patches.
For this situation, we may as well go with what we've got I think.
Linux is very straightforward. I don't know anything about Macs. I do know
that the Windows varients complicate things quite a bit.
> >
> > To cut a long story short:
> > I would say yes for a ZIP file for every platform.
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/13/2016 12:13 AM, schrieb Kay Schenk:
> On Fri, Aug 12, 2016 at 1:38 PM, Marcus<ma...@wtnet.de> wrote:
>
>> Am 08/12/2016 10:01 PM, schrieb Patricia Shanahan:
>>
>>> On 8/12/2016 12:22 PM, Dennis E. Hamilton wrote:
>>> ...
>>>
>>>> [Anecdotal Side Note: I just discovered that the MD5 hash for the
>>>> 4.1.2 Windows .exe fails to check on my Windows system because of a
>>>> defect in the .md5 file. For reasons unknown, the md5sum tool that I
>>>> have requires exactly two spaces between the hash value and the name
>>>> of the file the hash is for. Once I fiddled around and added the
>>>> second space, it all checks. What is intriguing to me is that this
>>>> has not been reported by anyone, which is perhaps of greater concern
>>>> than the fact that MD5 is used [;<].
>>>>
>>>
>>> I may have encountered this problem, but just attributed it to my lack
>>> of familiarity with the tools. I had no problem using md5sum to compute
>>> the hash, and it matched the one in the file.
>>>
>>
>> Just to document this also:
>> I haven't noticed this problwm because I've taken the hash values from the
>> MD5 and SHA246 files and put it into the little program I have found. Then
>> it compared it with the computed onces from the tl.dll file.
>>
>> Marcus
>
>
> \u200bum...I computed the MD5 and SHA1 on the zip file contents not the tl.dll
> file.
> I hope this was right. I didn't look at the comps on Windows zip.
argh. Yes, of course it was the ZIP file and not the DLL as it has no hash.
Sorry
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Kay Schenk <ka...@gmail.com>.
On Fri, Aug 12, 2016 at 1:38 PM, Marcus <ma...@wtnet.de> wrote:
> Am 08/12/2016 10:01 PM, schrieb Patricia Shanahan:
>
>> On 8/12/2016 12:22 PM, Dennis E. Hamilton wrote:
>> ...
>>
>>> [Anecdotal Side Note: I just discovered that the MD5 hash for the
>>> 4.1.2 Windows .exe fails to check on my Windows system because of a
>>> defect in the .md5 file. For reasons unknown, the md5sum tool that I
>>> have requires exactly two spaces between the hash value and the name
>>> of the file the hash is for. Once I fiddled around and added the
>>> second space, it all checks. What is intriguing to me is that this
>>> has not been reported by anyone, which is perhaps of greater concern
>>> than the fact that MD5 is used [;<].
>>>
>>
>> I may have encountered this problem, but just attributed it to my lack
>> of familiarity with the tools. I had no problem using md5sum to compute
>> the hash, and it matched the one in the file.
>>
>
> Just to document this also:
> I haven't noticed this problwm because I've taken the hash values from the
> MD5 and SHA246 files and put it into the little program I have found. Then
> it compared it with the computed onces from the tl.dll file.
>
> Marcus
um...I computed the MD5 and SHA1 on the zip file contents not the tl.dll
file.
I hope this was right. I didn't look at the comps on Windows zip.
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/12/2016 10:01 PM, schrieb Patricia Shanahan:
> On 8/12/2016 12:22 PM, Dennis E. Hamilton wrote:
> ...
>> [Anecdotal Side Note: I just discovered that the MD5 hash for the
>> 4.1.2 Windows .exe fails to check on my Windows system because of a
>> defect in the .md5 file. For reasons unknown, the md5sum tool that I
>> have requires exactly two spaces between the hash value and the name
>> of the file the hash is for. Once I fiddled around and added the
>> second space, it all checks. What is intriguing to me is that this
>> has not been reported by anyone, which is perhaps of greater concern
>> than the fact that MD5 is used [;<].
>
> I may have encountered this problem, but just attributed it to my lack
> of familiarity with the tools. I had no problem using md5sum to compute
> the hash, and it matched the one in the file.
Just to document this also:
I haven't noticed this problwm because I've taken the hash values from
the MD5 and SHA246 files and put it into the little program I have
found. Then it compared it with the computed onces from the tl.dll file.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Patricia Shanahan <pa...@acm.org>.
On 8/12/2016 12:22 PM, Dennis E. Hamilton wrote:
...
> [Anecdotal Side Note: I just discovered that the MD5 hash for the
> 4.1.2 Windows .exe fails to check on my Windows system because of a
> defect in the .md5 file. For reasons unknown, the md5sum tool that I
> have requires exactly two spaces between the hash value and the name
> of the file the hash is for. Once I fiddled around and added the
> second space, it all checks. What is intriguing to me is that this
> has not been reported by anyone, which is perhaps of greater concern
> than the fact that MD5 is used [;<].
I may have encountered this problem, but just attributed it to my lack
of familiarity with the tools. I had no problem using md5sum to compute
the hash, and it matched the one in the file.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Don Lewis <tr...@apache.org>.
On 12 Aug, Dennis E. Hamilton wrote:
>
>
>> -----Original Message-----
>> From: Don Lewis [mailto:truckman@apache.org]
>> Sent: Thursday, August 11, 2016 14:41
>> To: dev@openoffice.apache.org; kschenk@apache.org
>> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
>> Applying openoffice-4.1.2-patch1 for Windows)
>>
>> On 11 Aug, Kay Schenk@apache.org wrote:
>> >
>> >
>> > On 08/11/2016 12:50 PM, Kay Schenk@apache.org wrote:
>> >>
>> >>
>> >> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>> >>> [top posting]
>> >>> I'm in the process of trying to "sync" instructions for Linux32,
>> >>> Linux64, and MacOSX at the moment. As far as instructions on the
>> >>> actual HOTFIX page, we need to have just a "general" instruction
>> >>> for ALL zips that simply says -- "Unzip this package to some
>> >>> folder of your choosing and read the README that's included."
>> >>> Everything else should be in the various READMEs for each
>> >>> platform.
>> >>>
>> >>> I should be done with all edits by this evening for a final
>> >>> review before zipping and signing.
>> >>
>> >> Ok, I've now moved on to creating zip files, etc for Linux32,
>> >> Linux64 and Mac.
>> >>
>> >> My openssl version on does NOT supply digest sha256. Is it OK to
>> >> use sha1? MD5 already computed for each of these.
>> >
>> > sha1 is referenced on the ASF code signing page so I decided it was
>> OK. :)
>>
>> I'm really surprised that ASF requires MD5 since it was broken long
>> ago. Even SHA1 is now regarded as a weak hash.
> [orcmid]
>
> I think it depends on shrinking the attack surface and also what the
> MD5 is being used for. In the present case, it is extremely difficult
> to construct a Zip that has different usable content and the same
> hash. It would require adding extra content until the correct hash is
> duplicated despite alteration of the key payload, and that should
> become rather evident. I think the main reason for keeping it is that
> checking the MD5 is still more widely available to users. It may not
> be foolproof but it is better than not.
>
> And yes, collisions are possible and can be manufactured, but having
> one that accomplishes something can be rather tricky. The
> proofs-of-concept involve alterations that aren't visible and won't be
> noticed. Somebody will notice and it is not clear that the possible
> benefit is worth the effort to pull it off, especially against the
> risk of discovery.
>
> Hmm, one thing we could do is add the length of the zip in the README.
> (It takes a little work, but can be done, even when the (signed)
> README is inside the Zip. That's another nice reason for having the
> signed README also available for independent download outside of the
> Zip and only downloadable from the ASF archive site, along with the
> different hashes and the package's signature.
Adding the length definitely raises the bar. When downloading
third-party source tarballs to build FreeBSD packages, both the hash and
file size are checked. Even so, FreeBSD has switched from md5, to sha1,
and now sha256 for the hash.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Don Lewis [mailto:truckman@apache.org]
> Sent: Thursday, August 11, 2016 14:41
> To: dev@openoffice.apache.org; kschenk@apache.org
> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
> Applying openoffice-4.1.2-patch1 for Windows)
>
> On 11 Aug, Kay Schenk@apache.org wrote:
> >
> >
> > On 08/11/2016 12:50 PM, Kay Schenk@apache.org wrote:
> >>
> >>
> >> On 08/09/2016 02:12 PM, Kay Schenk wrote:
> >>> [top posting]
> >>> I'm in the process of trying to "sync" instructions for Linux32,
> >>> Linux64, and MacOSX at the moment. As far as instructions on the
> >>> actual HOTFIX page, we need to have just a "general" instruction for
> >>> ALL zips that simply says -- "Unzip this package to some folder of
> >>> your choosing and read the README that's included." Everything else
> >>> should be in the various READMEs for each platform.
> >>>
> >>> I should be done with all edits by this evening for a final review
> >>> before zipping and signing.
> >>
> >> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
> >> and Mac.
> >>
> >> My openssl version on does NOT supply digest sha256. Is it OK to use
> >> sha1? MD5 already computed for each of these.
> >
> > sha1 is referenced on the ASF code signing page so I decided it was
> OK. :)
>
> I'm really surprised that ASF requires MD5 since it was broken long ago.
> Even SHA1 is now regarded as a weak hash.
[orcmid]
I think it depends on shrinking the attack surface and also what the MD5 is being used for. In the present case, it is extremely difficult to construct a Zip that has different usable content and the same hash. It would require adding extra content until the correct hash is duplicated despite alteration of the key payload, and that should become rather evident. I think the main reason for keeping it is that checking the MD5 is still more widely available to users. It may not be foolproof but it is better than not.
And yes, collisions are possible and can be manufactured, but having one that accomplishes something can be rather tricky. The proofs-of-concept involve alterations that aren't visible and won't be noticed. Somebody will notice and it is not clear that the possible benefit is worth the effort to pull it off, especially against the risk of discovery.
Hmm, one thing we could do is add the length of the zip in the README. (It takes a little work, but can be done, even when the (signed) README is inside the Zip. That's another nice reason for having the signed README also available for independent download outside of the Zip and only downloadable from the ASF archive site, along with the different hashes and the package's signature.
[Anecdotal Side Note: I just discovered that the MD5 hash for the 4.1.2 Windows .exe fails to check on my Windows system because of a defect in the .md5 file. For reasons unknown, the md5sum tool that I have requires exactly two spaces between the hash value and the name of the file the hash is for. Once I fiddled around and added the second space, it all checks. What is intriguing to me is that this has not been reported by anyone, which is perhaps of greater concern than the fact that MD5 is used [;<].
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Don Lewis <tr...@apache.org>.
On 11 Aug, Kay Schenk@apache.org wrote:
>
>
> On 08/11/2016 12:50 PM, Kay Schenk@apache.org wrote:
>>
>>
>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>> [top posting]
>>> I'm in the process of trying to "sync" instructions for Linux32,
>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>> actual HOTFIX page, we need to have just a "general" instruction for
>>> ALL zips that simply says -- "Unzip this package to some folder of
>>> your choosing and read the README that's included." Everything else
>>> should be in the various READMEs for each platform.
>>>
>>> I should be done with all edits by this evening for a final review
>>> before zipping and signing.
>>
>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>> and Mac.
>>
>> My openssl version on does NOT supply digest sha256. Is it OK to use
>> sha1? MD5 already computed for each of these.
>
> sha1 is referenced on the ASF code signing page so I decided it was OK. :)
I'm really surprised that ASF requires MD5 since it was broken long ago.
Even SHA1 is now regarded as a weak hash.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by "Kay Schenk@apache.org" <ks...@apache.org>.
On 08/11/2016 12:50 PM, Kay Schenk@apache.org wrote:
>
>
> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>> [top posting]
>> I'm in the process of trying to "sync" instructions for Linux32,
>> Linux64, and MacOSX at the moment. As far as instructions on the actual
>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>> that simply says -- "Unzip this package to some folder of your choosing
>> and read the README that's included." Everything else should be in the
>> various READMEs for each platform.
>>
>> I should be done with all edits by this evening for a final review
>> before zipping and signing.
>
> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
> and Mac.
>
> My openssl version on does NOT supply digest sha256. Is it OK to use
> sha1? MD5 already computed for each of these.
sha1 is referenced on the ASF code signing page so I decided it was OK. :)
So I think I'm done with the Linux32, Linux64, and MacOSX zip artifacts.
Please check at:
https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/
If anything's amiss, it's likely I can't get back to this until Sunday.
Or feel free to fix.
>
>>
>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>>>
>>>> -----Original Message-----
>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>> Sent: Thursday, August 4, 2016 15:52
>>>> To: dev@openoffice.apache.org
>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>
>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>> [ ... ]
>>>>>
>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>
>>>>> Should we get started on these?
>>>>
>>>> it depends what we want that they should contain. The ZIP file for
>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>> installation. Also the ASC is not necessary as we provide it already
>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>> [orcmid]
>>>
>>> I think there is a misunderstanding. Two matters:
>>>
>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>>>
>>> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>>>
>>> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>>>>
>>>> That means that only the README and library file remains.
>>>>
>>>> When the README for Windows keep its length then I don't want to copy
>>>> this on the dowload webpage. ;-)
>>>>
>>>> So, when we put the README for all platforms in their ZIP files then we
>>>> can just put a pointer to it on the download webpage and thats it.
>>> [orcmid]
>>>
>>> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
>>>
>>> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>>>
>>> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
>>>
>>> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>>>
>>>>
>>>> To cut a long story short:
>>>> I would say yes for a ZIP file for every platform.
>>> [ ... ]
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>
--
Kay Schenk
Apache OpenOffice
----------------------------------------
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/13/2016 10:39 PM, schrieb Kay Schenk:
>
> On 08/13/2016 09:46 AM, Marcus wrote:
>> Am 08/13/2016 06:24 PM, schrieb Kay Schenk:
>>>
>>> On 08/13/2016 07:00 AM, Marcus wrote:
>>>> Here are my tests:
>>>>
>>>> Linux 32-bit:
>>>>
>>>> - ZIP file is OK and can be uncompressed
>>>> - MD5, SHA1 are OK [1]
>>>> - ZIP ASC is OK (signature from Kay Schenk)
>>>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>>>
>>>> Linux 64-bit:
>>>>
>>>> - ZIP file is OK and can be uncompressed
>>>> - MD5, SHA1 are OK [1]
>>>> - ZIP ASC is OK (signature from Kay Schenk)
>>>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>>>
>>>> Mac OSX:
>>>>
>>>> - ZIP file is OK and can be uncompressed
>>>> - MD5, SHA1 are OK [1]
>>>> - ZIP ASC is OK (signature from Kay Schenk)
>>>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>>>
>>>> However, after rewriting the files (of course without to modify the hash
>>>> values itself) the comparsion was OK.
>>>>
>>>> @Kay:
>>>> I've uploaded the sha256 hash files as suggested.
>>>
>>> YAY! Good job!
>>>
>>> Do you mind when I
>>>> overwrite the other hash files with the ones I've created? Then all have
>>>> the same format.
>>>
>>> No, go right ahead. With the openssl with digest options, this is how
>>> they got formatted.
>>
>> OK, done
>>
>>>> Furthermore, I've read the Readme's for Linux [2] and Mac. As I didn't
>>>> wanted to simply overwrite your work, I've attached the modified
>>>> versions. So, you can review them first or I can overwrite them if you
>>>> don't mind.
>>>
>>> I assumed this part --
>>>
>>> "Download the hotfix ZIP file to a location on your PC where it can be
>>> used and its content extracted.
>>>
>>> Example:
>>> User Jane downloaded and extracted the hotfix ZIP file from her browser
>>> window and saved it in a folder called "Downloads". The full path is:
>>>
>>> /home/jane/Downloads"
>>>
>>> would be on the hotfix page itself so not needed as part of the actual
>>> instructions. The rest of the changes look fine.
>>
>> OK, but when we keep the Readme's also outside of the ZIP files it could
>> make sense to keep this text part.
>>
>> Otherwise I can delete the part and just upload the Readme's.
>>
>> Marcus
>>
>>
>
> OK, upload this new version of README to be outside the zip. Otherwise,
> we need to redo the zips, recompute checksums etc.
>
> Thanks again for re-doing the checksums.
I know it's some effort. But having 2 different Readme files for the
same platform is not optimal. I've added some more details, so it's
easier to follow the instructions.
I've uploaded the 3 Readme files.
Marcus
>>>> [1] The files are not well formatted for the "md5sum" and "sha1sum"
>>>> commands. They need the following format:
>>>>
>>>> <hash value><space><space><file name>
>>>>
>>>> [2] The Readmes for Linux 32-bit and 64-bit are the same. I've just
>>>> attached the one for 32-bit.
>>>>
>>>> Marcus
>>>>
>>>>
>>>>
>>>> Am 08/12/2016 06:21 PM, schrieb Kay Schenk:
>>>>> On Thu, Aug 11, 2016 at 3:27 PM, Marcus<ma...@wtnet.de> wrote:
>>>>>
>>>>>> Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>>>>>>
>>>>>>>
>>>>>>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>>>>>>
>>>>>>>> [top posting]
>>>>>>>> I'm in the process of trying to "sync" instructions for Linux32,
>>>>>>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>>>>>>> actual
>>>>>>>> HOTFIX page, we need to have just a "general" instruction for ALL
>>>>>>>> zips
>>>>>>>> that simply says -- "Unzip this package to some folder of your
>>>>>>>> choosing
>>>>>>>> and read the README that's included." Everything else should be
>>>>>>>> in the
>>>>>>>> various READMEs for each platform.
>>>>>>>>
>>>>>>>> I should be done with all edits by this evening for a final review
>>>>>>>> before zipping and signing.
>>>>>>>>
>>>>>>>
>>>>>>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>>>>>>> and Mac.
>>>>>>>
>>>>>>> My openssl version on does NOT supply digest sha256. Is it OK to use
>>>>>>> sha1? MD5 already computed for each of these.
>>>>>>>
>>>>>>
>>>>>> I like to have it consistent for all platforms. Therefore I'll
>>>>>> check the
>>>>>> ZIPs and deliver the sha256 hash files.
>>>>>>
>>>>>> Marcus
>>>>>
>>>>>
>>>>> \u200bThanks a bunch Marcus!
>>>>> \u200b
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>>>>>>
>>>>>>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>>>>>>>> [TESTING].
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>>>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>>>>>>> To: dev@openoffice.apache.org
>>>>>>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for
>>>>>>>>>> Windows
>>>>>>>>>>
>>>>>>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>>>>>>>>
>>>>>>>>> [ ... ]
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>>>>>>
>>>>>>>>>>> Should we get started on these?
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> it depends what we want that they should contain. The ZIP file for
>>>>>>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file
>>>>>>>>>> for
>>>>>>>>>> the DLL. As it is only a patch IMHO we don't need to provide
>>>>>>>>>> another
>>>>>>>>>> LICENSE and NOTICE file which is already available in the
>>>>>>>>>> OpenOffice
>>>>>>>>>> installation. Also the ASC is not necessary as we provide it
>>>>>>>>>> already
>>>>>>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>>>>>>>>
>>>>>>>>> [orcmid]
>>>>>>>>>
>>>>>>>>> I think there is a misunderstanding. Two matters:
>>>>>>>>>
>>>>>>>>> 1. The use of LICENSE is required by the ALv2 itself, and
>>>>>>>>> the ASF
>>>>>>>>> practice is to include NOTICE as well on binary distributions.
>>>>>>>>> The patch
>>>>>>>>> qualifies, especially when it is moved to general distribution.
>>>>>>>>> It is also
>>>>>>>>> easy and harmless to provide.
>>>>>>>>>
>>>>>>>>> 2. The reason for preserving the .asc on the shared-library
>>>>>>>>> binary is
>>>>>>>>> because it authenticates with respect to who produced it and
>>>>>>>>> establishes
>>>>>>>>> that it has not been modified as supplied in the package (or as
>>>>>>>>> the result
>>>>>>>>> of some glitch in creation of the Zip). It provides a level of
>>>>>>>>> accountability and, also, auditability.
>>>>>>>>>
>>>>>>>>> Even though few people will check all of these, they remain
>>>>>>>>> possible to
>>>>>>>>> be checked. Since this is a matter of security vulnerabilities and
>>>>>>>>> involves elevation of privilege to perform, I believe it is
>>>>>>>>> important to
>>>>>>>>> demonstrate diligence and care, so that users have confidence in
>>>>>>>>> this
>>>>>>>>> procedure to the extent they are comfortable. Also, if it becomes
>>>>>>>>> necessary to troubleshoot a problem with these patch applications,
>>>>>>>>> we have
>>>>>>>>> the means to authenticate what they are using to ensure there
>>>>>>>>> are no
>>>>>>>>> counterfeits being offered to users.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> That means that only the README and library file remains.
>>>>>>>>>>
>>>>>>>>>> When the README for Windows keep its length then I don't want to
>>>>>>>>>> copy
>>>>>>>>>> this on the dowload webpage. ;-)
>>>>>>>>>>
>>>>>>>>>> So, when we put the README for all platforms in their ZIP files
>>>>>>>>>> then we
>>>>>>>>>> can just put a pointer to it on the download webpage and thats it.
>>>>>>>>>>
>>>>>>>>> [orcmid]
>>>>>>>>>
>>>>>>>>> Yes, that seems like a fine idea. The README can be linked the
>>>>>>>>> same
>>>>>>>>> way the .md5, .sha256, and .asc are linked.
>>>>>>>>>
>>>>>>>>> Also, the README may become simpler if we can link to some of the
>>>>>>>>> information and not have so much detail in the README text
>>>>>>>>> itself. It
>>>>>>>>> might even be useful to have an .html README for that matter. But
>>>>>>>>> that is
>>>>>>>>> all extra. Right now I think we want to get into the testing and
>>>>>>>>> see how
>>>>>>>>> to smooth what we have.
>>>>>>>>>
>>>>>>>>> PS: A friend of mine is looking into the MacOSX situation. He
>>>>>>>>> points
>>>>>>>>> out that one can use the Finder to do the job without users having
>>>>>>>>> to use
>>>>>>>>> Terminal sessions. I don't have further information at this time.
>>>>>>>>>
>>>>>>>>> PPS: The inclusion of scripts that do the job is also worthy of
>>>>>>>>> consideration, perhaps making it unnecessary to build
>>>>>>>>> executables. I will
>>>>>>>>> be looking at finding a .bat file that works safely for the
>>>>>>>>> Windows case.
>>>>>>>>> That can make the instructions much shorter :).
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> To cut a long story short:
>>>>>>>>>> I would say yes for a ZIP file for every platform.
>>>>>>>>>>
>>>>>>>>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Kay Schenk <ka...@gmail.com>.
On 08/13/2016 09:46 AM, Marcus wrote:
> Am 08/13/2016 06:24 PM, schrieb Kay Schenk:
>>
>> On 08/13/2016 07:00 AM, Marcus wrote:
>>> Here are my tests:
>>>
>>> Linux 32-bit:
>>>
>>> - ZIP file is OK and can be uncompressed
>>> - MD5, SHA1 are OK [1]
>>> - ZIP ASC is OK (signature from Kay Schenk)
>>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>>
>>> Linux 64-bit:
>>>
>>> - ZIP file is OK and can be uncompressed
>>> - MD5, SHA1 are OK [1]
>>> - ZIP ASC is OK (signature from Kay Schenk)
>>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>>
>>> Mac OSX:
>>>
>>> - ZIP file is OK and can be uncompressed
>>> - MD5, SHA1 are OK [1]
>>> - ZIP ASC is OK (signature from Kay Schenk)
>>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>>
>>> However, after rewriting the files (of course without to modify the hash
>>> values itself) the comparsion was OK.
>>>
>>> @Kay:
>>> I've uploaded the sha256 hash files as suggested.
>>
>> YAY! Good job!
>>
>> Do you mind when I
>>> overwrite the other hash files with the ones I've created? Then all have
>>> the same format.
>>
>> No, go right ahead. With the openssl with digest options, this is how
>> they got formatted.
>
> OK, done
>
>>> Furthermore, I've read the Readme's for Linux [2] and Mac. As I didn't
>>> wanted to simply overwrite your work, I've attached the modified
>>> versions. So, you can review them first or I can overwrite them if you
>>> don't mind.
>>
>> I assumed this part --
>>
>> "Download the hotfix ZIP file to a location on your PC where it can be
>> used and its content extracted.
>>
>> Example:
>> User Jane downloaded and extracted the hotfix ZIP file from her browser
>> window and saved it in a folder called "Downloads". The full path is:
>>
>> /home/jane/Downloads"
>>
>> would be on the hotfix page itself so not needed as part of the actual
>> instructions. The rest of the changes look fine.
>
> OK, but when we keep the Readme's also outside of the ZIP files it could
> make sense to keep this text part.
>
> Otherwise I can delete the part and just upload the Readme's.
>
> Marcus
>
>
OK, upload this new version of README to be outside the zip. Otherwise,
we need to redo the zips, recompute checksums etc.
Thanks again for re-doing the checksums.
>
>>> [1] The files are not well formatted for the "md5sum" and "sha1sum"
>>> commands. They need the following format:
>>>
>>> <hash value><space><space><file name>
>>>
>>> [2] The Readmes for Linux 32-bit and 64-bit are the same. I've just
>>> attached the one for 32-bit.
>>>
>>> Marcus
>>>
>>>
>>>
>>> Am 08/12/2016 06:21 PM, schrieb Kay Schenk:
>>>> On Thu, Aug 11, 2016 at 3:27 PM, Marcus<ma...@wtnet.de> wrote:
>>>>
>>>>> Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>>>>>
>>>>>>
>>>>>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>>>>>
>>>>>>> [top posting]
>>>>>>> I'm in the process of trying to "sync" instructions for Linux32,
>>>>>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>>>>>> actual
>>>>>>> HOTFIX page, we need to have just a "general" instruction for ALL
>>>>>>> zips
>>>>>>> that simply says -- "Unzip this package to some folder of your
>>>>>>> choosing
>>>>>>> and read the README that's included." Everything else should be
>>>>>>> in the
>>>>>>> various READMEs for each platform.
>>>>>>>
>>>>>>> I should be done with all edits by this evening for a final review
>>>>>>> before zipping and signing.
>>>>>>>
>>>>>>
>>>>>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>>>>>> and Mac.
>>>>>>
>>>>>> My openssl version on does NOT supply digest sha256. Is it OK to use
>>>>>> sha1? MD5 already computed for each of these.
>>>>>>
>>>>>
>>>>> I like to have it consistent for all platforms. Therefore I'll
>>>>> check the
>>>>> ZIPs and deliver the sha256 hash files.
>>>>>
>>>>> Marcus
>>>>
>>>>
>>>> \u200bThanks a bunch Marcus!
>>>> \u200b
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>>>>>
>>>>>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>>>>>>> [TESTING].
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>>>>>> To: dev@openoffice.apache.org
>>>>>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for
>>>>>>>>> Windows
>>>>>>>>>
>>>>>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>>>>>>>
>>>>>>>> [ ... ]
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>>>>>
>>>>>>>>>> Should we get started on these?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> it depends what we want that they should contain. The ZIP file for
>>>>>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file
>>>>>>>>> for
>>>>>>>>> the DLL. As it is only a patch IMHO we don't need to provide
>>>>>>>>> another
>>>>>>>>> LICENSE and NOTICE file which is already available in the
>>>>>>>>> OpenOffice
>>>>>>>>> installation. Also the ASC is not necessary as we provide it
>>>>>>>>> already
>>>>>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>>>>>>>
>>>>>>>> [orcmid]
>>>>>>>>
>>>>>>>> I think there is a misunderstanding. Two matters:
>>>>>>>>
>>>>>>>> 1. The use of LICENSE is required by the ALv2 itself, and
>>>>>>>> the ASF
>>>>>>>> practice is to include NOTICE as well on binary distributions.
>>>>>>>> The patch
>>>>>>>> qualifies, especially when it is moved to general distribution.
>>>>>>>> It is also
>>>>>>>> easy and harmless to provide.
>>>>>>>>
>>>>>>>> 2. The reason for preserving the .asc on the shared-library
>>>>>>>> binary is
>>>>>>>> because it authenticates with respect to who produced it and
>>>>>>>> establishes
>>>>>>>> that it has not been modified as supplied in the package (or as
>>>>>>>> the result
>>>>>>>> of some glitch in creation of the Zip). It provides a level of
>>>>>>>> accountability and, also, auditability.
>>>>>>>>
>>>>>>>> Even though few people will check all of these, they remain
>>>>>>>> possible to
>>>>>>>> be checked. Since this is a matter of security vulnerabilities and
>>>>>>>> involves elevation of privilege to perform, I believe it is
>>>>>>>> important to
>>>>>>>> demonstrate diligence and care, so that users have confidence in
>>>>>>>> this
>>>>>>>> procedure to the extent they are comfortable. Also, if it becomes
>>>>>>>> necessary to troubleshoot a problem with these patch applications,
>>>>>>>> we have
>>>>>>>> the means to authenticate what they are using to ensure there
>>>>>>>> are no
>>>>>>>> counterfeits being offered to users.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> That means that only the README and library file remains.
>>>>>>>>>
>>>>>>>>> When the README for Windows keep its length then I don't want to
>>>>>>>>> copy
>>>>>>>>> this on the dowload webpage. ;-)
>>>>>>>>>
>>>>>>>>> So, when we put the README for all platforms in their ZIP files
>>>>>>>>> then we
>>>>>>>>> can just put a pointer to it on the download webpage and thats it.
>>>>>>>>>
>>>>>>>> [orcmid]
>>>>>>>>
>>>>>>>> Yes, that seems like a fine idea. The README can be linked the
>>>>>>>> same
>>>>>>>> way the .md5, .sha256, and .asc are linked.
>>>>>>>>
>>>>>>>> Also, the README may become simpler if we can link to some of the
>>>>>>>> information and not have so much detail in the README text
>>>>>>>> itself. It
>>>>>>>> might even be useful to have an .html README for that matter. But
>>>>>>>> that is
>>>>>>>> all extra. Right now I think we want to get into the testing and
>>>>>>>> see how
>>>>>>>> to smooth what we have.
>>>>>>>>
>>>>>>>> PS: A friend of mine is looking into the MacOSX situation. He
>>>>>>>> points
>>>>>>>> out that one can use the Finder to do the job without users having
>>>>>>>> to use
>>>>>>>> Terminal sessions. I don't have further information at this time.
>>>>>>>>
>>>>>>>> PPS: The inclusion of scripts that do the job is also worthy of
>>>>>>>> consideration, perhaps making it unnecessary to build
>>>>>>>> executables. I will
>>>>>>>> be looking at finding a .bat file that works safely for the
>>>>>>>> Windows case.
>>>>>>>> That can make the instructions much shorter :).
>>>>>>>>
>>>>>>>>
>>>>>>>>> To cut a long story short:
>>>>>>>>> I would say yes for a ZIP file for every platform.
>>>>>>>>>
>>>>>>>> [ ... ]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/13/2016 06:24 PM, schrieb Kay Schenk:
>
> On 08/13/2016 07:00 AM, Marcus wrote:
>> Here are my tests:
>>
>> Linux 32-bit:
>>
>> - ZIP file is OK and can be uncompressed
>> - MD5, SHA1 are OK [1]
>> - ZIP ASC is OK (signature from Kay Schenk)
>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>
>> Linux 64-bit:
>>
>> - ZIP file is OK and can be uncompressed
>> - MD5, SHA1 are OK [1]
>> - ZIP ASC is OK (signature from Kay Schenk)
>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>
>> Mac OSX:
>>
>> - ZIP file is OK and can be uncompressed
>> - MD5, SHA1 are OK [1]
>> - ZIP ASC is OK (signature from Kay Schenk)
>> - Library ASC is OK (signature from Ariel Constenla-Haile)
>>
>> However, after rewriting the files (of course without to modify the hash
>> values itself) the comparsion was OK.
>>
>> @Kay:
>> I've uploaded the sha256 hash files as suggested.
>
> YAY! Good job!
>
> Do you mind when I
>> overwrite the other hash files with the ones I've created? Then all have
>> the same format.
>
> No, go right ahead. With the openssl with digest options, this is how
> they got formatted.
OK, done
>> Furthermore, I've read the Readme's for Linux [2] and Mac. As I didn't
>> wanted to simply overwrite your work, I've attached the modified
>> versions. So, you can review them first or I can overwrite them if you
>> don't mind.
>
> I assumed this part --
>
> "Download the hotfix ZIP file to a location on your PC where it can be
> used and its content extracted.
>
> Example:
> User Jane downloaded and extracted the hotfix ZIP file from her browser
> window and saved it in a folder called "Downloads". The full path is:
>
> /home/jane/Downloads"
>
> would be on the hotfix page itself so not needed as part of the actual
> instructions. The rest of the changes look fine.
OK, but when we keep the Readme's also outside of the ZIP files it could
make sense to keep this text part.
Otherwise I can delete the part and just upload the Readme's.
Marcus
>> [1] The files are not well formatted for the "md5sum" and "sha1sum"
>> commands. They need the following format:
>>
>> <hash value><space><space><file name>
>>
>> [2] The Readmes for Linux 32-bit and 64-bit are the same. I've just
>> attached the one for 32-bit.
>>
>> Marcus
>>
>>
>>
>> Am 08/12/2016 06:21 PM, schrieb Kay Schenk:
>>> On Thu, Aug 11, 2016 at 3:27 PM, Marcus<ma...@wtnet.de> wrote:
>>>
>>>> Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>>>>
>>>>>
>>>>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>>>>
>>>>>> [top posting]
>>>>>> I'm in the process of trying to "sync" instructions for Linux32,
>>>>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>>>>> actual
>>>>>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>>>>>> that simply says -- "Unzip this package to some folder of your
>>>>>> choosing
>>>>>> and read the README that's included." Everything else should be in the
>>>>>> various READMEs for each platform.
>>>>>>
>>>>>> I should be done with all edits by this evening for a final review
>>>>>> before zipping and signing.
>>>>>>
>>>>>
>>>>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>>>>> and Mac.
>>>>>
>>>>> My openssl version on does NOT supply digest sha256. Is it OK to use
>>>>> sha1? MD5 already computed for each of these.
>>>>>
>>>>
>>>> I like to have it consistent for all platforms. Therefore I'll check the
>>>> ZIPs and deliver the sha256 hash files.
>>>>
>>>> Marcus
>>>
>>>
>>> \u200bThanks a bunch Marcus!
>>> \u200b
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>>>>
>>>>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>>>>>> [TESTING].
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>>>>> To: dev@openoffice.apache.org
>>>>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>>>>>
>>>>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>>>>>>
>>>>>>> [ ... ]
>>>>>>>
>>>>>>>>
>>>>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>>>>
>>>>>>>>> Should we get started on these?
>>>>>>>>>
>>>>>>>>
>>>>>>>> it depends what we want that they should contain. The ZIP file for
>>>>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file
>>>>>>>> for
>>>>>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>>>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>>>>>> installation. Also the ASC is not necessary as we provide it already
>>>>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>>>>>>
>>>>>>> [orcmid]
>>>>>>>
>>>>>>> I think there is a misunderstanding. Two matters:
>>>>>>>
>>>>>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
>>>>>>> practice is to include NOTICE as well on binary distributions.
>>>>>>> The patch
>>>>>>> qualifies, especially when it is moved to general distribution.
>>>>>>> It is also
>>>>>>> easy and harmless to provide.
>>>>>>>
>>>>>>> 2. The reason for preserving the .asc on the shared-library
>>>>>>> binary is
>>>>>>> because it authenticates with respect to who produced it and
>>>>>>> establishes
>>>>>>> that it has not been modified as supplied in the package (or as
>>>>>>> the result
>>>>>>> of some glitch in creation of the Zip). It provides a level of
>>>>>>> accountability and, also, auditability.
>>>>>>>
>>>>>>> Even though few people will check all of these, they remain
>>>>>>> possible to
>>>>>>> be checked. Since this is a matter of security vulnerabilities and
>>>>>>> involves elevation of privilege to perform, I believe it is
>>>>>>> important to
>>>>>>> demonstrate diligence and care, so that users have confidence in this
>>>>>>> procedure to the extent they are comfortable. Also, if it becomes
>>>>>>> necessary to troubleshoot a problem with these patch applications,
>>>>>>> we have
>>>>>>> the means to authenticate what they are using to ensure there are no
>>>>>>> counterfeits being offered to users.
>>>>>>>
>>>>>>>>
>>>>>>>> That means that only the README and library file remains.
>>>>>>>>
>>>>>>>> When the README for Windows keep its length then I don't want to
>>>>>>>> copy
>>>>>>>> this on the dowload webpage. ;-)
>>>>>>>>
>>>>>>>> So, when we put the README for all platforms in their ZIP files
>>>>>>>> then we
>>>>>>>> can just put a pointer to it on the download webpage and thats it.
>>>>>>>>
>>>>>>> [orcmid]
>>>>>>>
>>>>>>> Yes, that seems like a fine idea. The README can be linked the same
>>>>>>> way the .md5, .sha256, and .asc are linked.
>>>>>>>
>>>>>>> Also, the README may become simpler if we can link to some of the
>>>>>>> information and not have so much detail in the README text
>>>>>>> itself. It
>>>>>>> might even be useful to have an .html README for that matter. But
>>>>>>> that is
>>>>>>> all extra. Right now I think we want to get into the testing and
>>>>>>> see how
>>>>>>> to smooth what we have.
>>>>>>>
>>>>>>> PS: A friend of mine is looking into the MacOSX situation. He points
>>>>>>> out that one can use the Finder to do the job without users having
>>>>>>> to use
>>>>>>> Terminal sessions. I don't have further information at this time.
>>>>>>>
>>>>>>> PPS: The inclusion of scripts that do the job is also worthy of
>>>>>>> consideration, perhaps making it unnecessary to build
>>>>>>> executables. I will
>>>>>>> be looking at finding a .bat file that works safely for the
>>>>>>> Windows case.
>>>>>>> That can make the instructions much shorter :).
>>>>>>>
>>>>>>>
>>>>>>>> To cut a long story short:
>>>>>>>> I would say yes for a ZIP file for every platform.
>>>>>>>>
>>>>>>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Kay Schenk <ka...@gmail.com>.
On 08/13/2016 07:00 AM, Marcus wrote:
> Here are my tests:
>
> Linux 32-bit:
>
> - ZIP file is OK and can be uncompressed
> - MD5, SHA1 are OK [1]
> - ZIP ASC is OK (signature from Kay Schenk)
> - Library ASC is OK (signature from Ariel Constenla-Haile)
>
> Linux 64-bit:
>
> - ZIP file is OK and can be uncompressed
> - MD5, SHA1 are OK [1]
> - ZIP ASC is OK (signature from Kay Schenk)
> - Library ASC is OK (signature from Ariel Constenla-Haile)
>
> Mac OSX:
>
> - ZIP file is OK and can be uncompressed
> - MD5, SHA1 are OK [1]
> - ZIP ASC is OK (signature from Kay Schenk)
> - Library ASC is OK (signature from Ariel Constenla-Haile)
>
> However, after rewriting the files (of course without to modify the hash
> values itself) the comparsion was OK.
>
> @Kay:
> I've uploaded the sha256 hash files as suggested.
YAY! Good job!
Do you mind when I
> overwrite the other hash files with the ones I've created? Then all have
> the same format.
No, go right ahead. With the openssl with digest options, this is how
they got formatted.
>
> Furthermore, I've read the Readme's for Linux [2] and Mac. As I didn't
> wanted to simply overwrite your work, I've attached the modified
> versions. So, you can review them first or I can overwrite them if you
> don't mind.
I assumed this part --
"Download the hotfix ZIP file to a location on your PC where it can be
used and its content extracted.
Example:
User Jane downloaded and extracted the hotfix ZIP file from her browser
window and saved it in a folder called "Downloads". The full path is:
/home/jane/Downloads"
would be on the hotfix page itself so not needed as part of the actual
instructions. The rest of the changes look fine.
>
> [1] The files are not well formatted for the "md5sum" and "sha1sum"
> commands. They need the following format:
>
> <hash value><space><space><file name>
>
> [2] The Readmes for Linux 32-bit and 64-bit are the same. I've just
> attached the one for 32-bit.
>
> Marcus
>
>
>
> Am 08/12/2016 06:21 PM, schrieb Kay Schenk:
>> On Thu, Aug 11, 2016 at 3:27 PM, Marcus<ma...@wtnet.de> wrote:
>>
>>> Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>>>
>>>>
>>>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>>>
>>>>> [top posting]
>>>>> I'm in the process of trying to "sync" instructions for Linux32,
>>>>> Linux64, and MacOSX at the moment. As far as instructions on the
>>>>> actual
>>>>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>>>>> that simply says -- "Unzip this package to some folder of your
>>>>> choosing
>>>>> and read the README that's included." Everything else should be in the
>>>>> various READMEs for each platform.
>>>>>
>>>>> I should be done with all edits by this evening for a final review
>>>>> before zipping and signing.
>>>>>
>>>>
>>>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>>>> and Mac.
>>>>
>>>> My openssl version on does NOT supply digest sha256. Is it OK to use
>>>> sha1? MD5 already computed for each of these.
>>>>
>>>
>>> I like to have it consistent for all platforms. Therefore I'll check the
>>> ZIPs and deliver the sha256 hash files.
>>>
>>> Marcus
>>
>>
>> \u200bThanks a bunch Marcus!
>> \u200b
>>
>>
>>>
>>>
>>>
>>>
>>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>>>
>>>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>>>>> [TESTING].
>>>>>>
>>>>>> -----Original Message-----
>>>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>>>> To: dev@openoffice.apache.org
>>>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>>>>
>>>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>>>>>
>>>>>> [ ... ]
>>>>>>
>>>>>>>
>>>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>>>
>>>>>>>> Should we get started on these?
>>>>>>>>
>>>>>>>
>>>>>>> it depends what we want that they should contain. The ZIP file for
>>>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file
>>>>>>> for
>>>>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>>>>> installation. Also the ASC is not necessary as we provide it already
>>>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>>>>>
>>>>>> [orcmid]
>>>>>>
>>>>>> I think there is a misunderstanding. Two matters:
>>>>>>
>>>>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
>>>>>> practice is to include NOTICE as well on binary distributions.
>>>>>> The patch
>>>>>> qualifies, especially when it is moved to general distribution.
>>>>>> It is also
>>>>>> easy and harmless to provide.
>>>>>>
>>>>>> 2. The reason for preserving the .asc on the shared-library
>>>>>> binary is
>>>>>> because it authenticates with respect to who produced it and
>>>>>> establishes
>>>>>> that it has not been modified as supplied in the package (or as
>>>>>> the result
>>>>>> of some glitch in creation of the Zip). It provides a level of
>>>>>> accountability and, also, auditability.
>>>>>>
>>>>>> Even though few people will check all of these, they remain
>>>>>> possible to
>>>>>> be checked. Since this is a matter of security vulnerabilities and
>>>>>> involves elevation of privilege to perform, I believe it is
>>>>>> important to
>>>>>> demonstrate diligence and care, so that users have confidence in this
>>>>>> procedure to the extent they are comfortable. Also, if it becomes
>>>>>> necessary to troubleshoot a problem with these patch applications,
>>>>>> we have
>>>>>> the means to authenticate what they are using to ensure there are no
>>>>>> counterfeits being offered to users.
>>>>>>
>>>>>>>
>>>>>>> That means that only the README and library file remains.
>>>>>>>
>>>>>>> When the README for Windows keep its length then I don't want to
>>>>>>> copy
>>>>>>> this on the dowload webpage. ;-)
>>>>>>>
>>>>>>> So, when we put the README for all platforms in their ZIP files
>>>>>>> then we
>>>>>>> can just put a pointer to it on the download webpage and thats it.
>>>>>>>
>>>>>> [orcmid]
>>>>>>
>>>>>> Yes, that seems like a fine idea. The README can be linked the same
>>>>>> way the .md5, .sha256, and .asc are linked.
>>>>>>
>>>>>> Also, the README may become simpler if we can link to some of the
>>>>>> information and not have so much detail in the README text
>>>>>> itself. It
>>>>>> might even be useful to have an .html README for that matter. But
>>>>>> that is
>>>>>> all extra. Right now I think we want to get into the testing and
>>>>>> see how
>>>>>> to smooth what we have.
>>>>>>
>>>>>> PS: A friend of mine is looking into the MacOSX situation. He points
>>>>>> out that one can use the Finder to do the job without users having
>>>>>> to use
>>>>>> Terminal sessions. I don't have further information at this time.
>>>>>>
>>>>>> PPS: The inclusion of scripts that do the job is also worthy of
>>>>>> consideration, perhaps making it unnecessary to build
>>>>>> executables. I will
>>>>>> be looking at finding a .bat file that works safely for the
>>>>>> Windows case.
>>>>>> That can make the instructions much shorter :).
>>>>>>
>>>>>>
>>>>>>> To cut a long story short:
>>>>>>> I would say yes for a ZIP file for every platform.
>>>>>>>
>>>>>> [ ... ]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Here are my tests:
Linux 32-bit:
- ZIP file is OK and can be uncompressed
- MD5, SHA1 are OK [1]
- ZIP ASC is OK (signature from Kay Schenk)
- Library ASC is OK (signature from Ariel Constenla-Haile)
Linux 64-bit:
- ZIP file is OK and can be uncompressed
- MD5, SHA1 are OK [1]
- ZIP ASC is OK (signature from Kay Schenk)
- Library ASC is OK (signature from Ariel Constenla-Haile)
Mac OSX:
- ZIP file is OK and can be uncompressed
- MD5, SHA1 are OK [1]
- ZIP ASC is OK (signature from Kay Schenk)
- Library ASC is OK (signature from Ariel Constenla-Haile)
However, after rewriting the files (of course without to modify the hash
values itself) the comparsion was OK.
@Kay:
I've uploaded the sha256 hash files as suggested. Do you mind when I
overwrite the other hash files with the ones I've created? Then all have
the same format.
Furthermore, I've read the Readme's for Linux [2] and Mac. As I didn't
wanted to simply overwrite your work, I've attached the modified
versions. So, you can review them first or I can overwrite them if you
don't mind.
[1] The files are not well formatted for the "md5sum" and "sha1sum"
commands. They need the following format:
<hash value><space><space><file name>
[2] The Readmes for Linux 32-bit and 64-bit are the same. I've just
attached the one for 32-bit.
Marcus
Am 08/12/2016 06:21 PM, schrieb Kay Schenk:
> On Thu, Aug 11, 2016 at 3:27 PM, Marcus<ma...@wtnet.de> wrote:
>
>> Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>>
>>>
>>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>>
>>>> [top posting]
>>>> I'm in the process of trying to "sync" instructions for Linux32,
>>>> Linux64, and MacOSX at the moment. As far as instructions on the actual
>>>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>>>> that simply says -- "Unzip this package to some folder of your choosing
>>>> and read the README that's included." Everything else should be in the
>>>> various READMEs for each platform.
>>>>
>>>> I should be done with all edits by this evening for a final review
>>>> before zipping and signing.
>>>>
>>>
>>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>>> and Mac.
>>>
>>> My openssl version on does NOT supply digest sha256. Is it OK to use
>>> sha1? MD5 already computed for each of these.
>>>
>>
>> I like to have it consistent for all platforms. Therefore I'll check the
>> ZIPs and deliver the sha256 hash files.
>>
>> Marcus
>
>
> \u200bThanks a bunch Marcus!
> \u200b
>
>
>>
>>
>>
>>
>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>>
>>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>>>> [TESTING].
>>>>>
>>>>> -----Original Message-----
>>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>>> To: dev@openoffice.apache.org
>>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>>>
>>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>>>>
>>>>> [ ... ]
>>>>>
>>>>>>
>>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>>
>>>>>>> Should we get started on these?
>>>>>>>
>>>>>>
>>>>>> it depends what we want that they should contain. The ZIP file for
>>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>>>> installation. Also the ASC is not necessary as we provide it already
>>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>>>>
>>>>> [orcmid]
>>>>>
>>>>> I think there is a misunderstanding. Two matters:
>>>>>
>>>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
>>>>> practice is to include NOTICE as well on binary distributions. The patch
>>>>> qualifies, especially when it is moved to general distribution. It is also
>>>>> easy and harmless to provide.
>>>>>
>>>>> 2. The reason for preserving the .asc on the shared-library binary is
>>>>> because it authenticates with respect to who produced it and establishes
>>>>> that it has not been modified as supplied in the package (or as the result
>>>>> of some glitch in creation of the Zip). It provides a level of
>>>>> accountability and, also, auditability.
>>>>>
>>>>> Even though few people will check all of these, they remain possible to
>>>>> be checked. Since this is a matter of security vulnerabilities and
>>>>> involves elevation of privilege to perform, I believe it is important to
>>>>> demonstrate diligence and care, so that users have confidence in this
>>>>> procedure to the extent they are comfortable. Also, if it becomes
>>>>> necessary to troubleshoot a problem with these patch applications, we have
>>>>> the means to authenticate what they are using to ensure there are no
>>>>> counterfeits being offered to users.
>>>>>
>>>>>>
>>>>>> That means that only the README and library file remains.
>>>>>>
>>>>>> When the README for Windows keep its length then I don't want to copy
>>>>>> this on the dowload webpage. ;-)
>>>>>>
>>>>>> So, when we put the README for all platforms in their ZIP files then we
>>>>>> can just put a pointer to it on the download webpage and thats it.
>>>>>>
>>>>> [orcmid]
>>>>>
>>>>> Yes, that seems like a fine idea. The README can be linked the same
>>>>> way the .md5, .sha256, and .asc are linked.
>>>>>
>>>>> Also, the README may become simpler if we can link to some of the
>>>>> information and not have so much detail in the README text itself. It
>>>>> might even be useful to have an .html README for that matter. But that is
>>>>> all extra. Right now I think we want to get into the testing and see how
>>>>> to smooth what we have.
>>>>>
>>>>> PS: A friend of mine is looking into the MacOSX situation. He points
>>>>> out that one can use the Finder to do the job without users having to use
>>>>> Terminal sessions. I don't have further information at this time.
>>>>>
>>>>> PPS: The inclusion of scripts that do the job is also worthy of
>>>>> consideration, perhaps making it unnecessary to build executables. I will
>>>>> be looking at finding a .bat file that works safely for the Windows case.
>>>>> That can make the instructions much shorter :).
>>>>>
>>>>>
>>>>>> To cut a long story short:
>>>>>> I would say yes for a ZIP file for every platform.
>>>>>>
>>>>> [ ... ]
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Kay Schenk <ka...@gmail.com>.
On Thu, Aug 11, 2016 at 3:27 PM, Marcus <ma...@wtnet.de> wrote:
> Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>
>>
>> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>>
>>> [top posting]
>>> I'm in the process of trying to "sync" instructions for Linux32,
>>> Linux64, and MacOSX at the moment. As far as instructions on the actual
>>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>>> that simply says -- "Unzip this package to some folder of your choosing
>>> and read the README that's included." Everything else should be in the
>>> various READMEs for each platform.
>>>
>>> I should be done with all edits by this evening for a final review
>>> before zipping and signing.
>>>
>>
>> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
>> and Mac.
>>
>> My openssl version on does NOT supply digest sha256. Is it OK to use
>> sha1? MD5 already computed for each of these.
>>
>
> I like to have it consistent for all platforms. Therefore I'll check the
> ZIPs and deliver the sha256 hash files.
>
> Marcus
Thanks a bunch Marcus!
>
>
>
>
> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>
>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>>>> [TESTING].
>>>>
>>>> -----Original Message-----
>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>> To: dev@openoffice.apache.org
>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>>
>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>>>
>>>> [ ... ]
>>>>
>>>>>
>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>
>>>>>> Should we get started on these?
>>>>>>
>>>>>
>>>>> it depends what we want that they should contain. The ZIP file for
>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>>> installation. Also the ASC is not necessary as we provide it already
>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>>>
>>>> [orcmid]
>>>>
>>>> I think there is a misunderstanding. Two matters:
>>>>
>>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
>>>> practice is to include NOTICE as well on binary distributions. The patch
>>>> qualifies, especially when it is moved to general distribution. It is also
>>>> easy and harmless to provide.
>>>>
>>>> 2. The reason for preserving the .asc on the shared-library binary is
>>>> because it authenticates with respect to who produced it and establishes
>>>> that it has not been modified as supplied in the package (or as the result
>>>> of some glitch in creation of the Zip). It provides a level of
>>>> accountability and, also, auditability.
>>>>
>>>> Even though few people will check all of these, they remain possible to
>>>> be checked. Since this is a matter of security vulnerabilities and
>>>> involves elevation of privilege to perform, I believe it is important to
>>>> demonstrate diligence and care, so that users have confidence in this
>>>> procedure to the extent they are comfortable. Also, if it becomes
>>>> necessary to troubleshoot a problem with these patch applications, we have
>>>> the means to authenticate what they are using to ensure there are no
>>>> counterfeits being offered to users.
>>>>
>>>>>
>>>>> That means that only the README and library file remains.
>>>>>
>>>>> When the README for Windows keep its length then I don't want to copy
>>>>> this on the dowload webpage. ;-)
>>>>>
>>>>> So, when we put the README for all platforms in their ZIP files then we
>>>>> can just put a pointer to it on the download webpage and thats it.
>>>>>
>>>> [orcmid]
>>>>
>>>> Yes, that seems like a fine idea. The README can be linked the same
>>>> way the .md5, .sha256, and .asc are linked.
>>>>
>>>> Also, the README may become simpler if we can link to some of the
>>>> information and not have so much detail in the README text itself. It
>>>> might even be useful to have an .html README for that matter. But that is
>>>> all extra. Right now I think we want to get into the testing and see how
>>>> to smooth what we have.
>>>>
>>>> PS: A friend of mine is looking into the MacOSX situation. He points
>>>> out that one can use the Finder to do the job without users having to use
>>>> Terminal sessions. I don't have further information at this time.
>>>>
>>>> PPS: The inclusion of scripts that do the job is also worthy of
>>>> consideration, perhaps making it unnecessary to build executables. I will
>>>> be looking at finding a .bat file that works safely for the Windows case.
>>>> That can make the instructions much shorter :).
>>>>
>>>>
>>>>> To cut a long story short:
>>>>> I would say yes for a ZIP file for every platform.
>>>>>
>>>> [ ... ]
>>>>
>>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
--
----------------------------------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/11/2016 09:50 PM, schrieb Kay Schenk@apache.org:
>
> On 08/09/2016 02:12 PM, Kay Schenk wrote:
>> [top posting]
>> I'm in the process of trying to "sync" instructions for Linux32,
>> Linux64, and MacOSX at the moment. As far as instructions on the actual
>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>> that simply says -- "Unzip this package to some folder of your choosing
>> and read the README that's included." Everything else should be in the
>> various READMEs for each platform.
>>
>> I should be done with all edits by this evening for a final review
>> before zipping and signing.
>
> Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
> and Mac.
>
> My openssl version on does NOT supply digest sha256. Is it OK to use
> sha1? MD5 already computed for each of these.
I like to have it consistent for all platforms. Therefore I'll check the
ZIPs and deliver the sha256 hash files.
Marcus
>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>>>
>>>> -----Original Message-----
>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>> Sent: Thursday, August 4, 2016 15:52
>>>> To: dev@openoffice.apache.org
>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>
>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>> [ ... ]
>>>>>
>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>
>>>>> Should we get started on these?
>>>>
>>>> it depends what we want that they should contain. The ZIP file for
>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>> installation. Also the ASC is not necessary as we provide it already
>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>> [orcmid]
>>>
>>> I think there is a misunderstanding. Two matters:
>>>
>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>>>
>>> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>>>
>>> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>>>>
>>>> That means that only the README and library file remains.
>>>>
>>>> When the README for Windows keep its length then I don't want to copy
>>>> this on the dowload webpage. ;-)
>>>>
>>>> So, when we put the README for all platforms in their ZIP files then we
>>>> can just put a pointer to it on the download webpage and thats it.
>>> [orcmid]
>>>
>>> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
>>>
>>> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>>>
>>> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
>>>
>>> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>>>
>>>>
>>>> To cut a long story short:
>>>> I would say yes for a ZIP file for every platform.
>>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Andrea Pescetti <pe...@apache.org>.
Kay Schenk wrote:
> My openssl version on does NOT supply digest sha256. Is it OK to use
> sha1? MD5 already computed for each of these.
Guidelines recommend SHA256. But it should not be difficult for you to
get a sha256sum binary or a generic shasum binary to run as "shasum
-a256 FILENAME".
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by "Kay Schenk@apache.org" <ks...@apache.org>.
On 08/09/2016 02:12 PM, Kay Schenk wrote:
> [top posting]
> I'm in the process of trying to "sync" instructions for Linux32,
> Linux64, and MacOSX at the moment. As far as instructions on the actual
> HOTFIX page, we need to have just a "general" instruction for ALL zips
> that simply says -- "Unzip this package to some folder of your choosing
> and read the README that's included." Everything else should be in the
> various READMEs for each platform.
>
> I should be done with all edits by this evening for a final review
> before zipping and signing.
Ok, I've now moved on to creating zip files, etc for Linux32, Linux64
and Mac.
My openssl version on does NOT supply digest sha256. Is it OK to use
sha1? MD5 already computed for each of these.
>
> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>>
>>> -----Original Message-----
>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>> Sent: Thursday, August 4, 2016 15:52
>>> To: dev@openoffice.apache.org
>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>
>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>> [ ... ]
>>>>
>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>
>>>> Should we get started on these?
>>>
>>> it depends what we want that they should contain. The ZIP file for
>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>> installation. Also the ASC is not necessary as we provide it already
>>> (together with MD5 and SHA256) for the whole ZIP file.
>> [orcmid]
>>
>> I think there is a misunderstanding. Two matters:
>>
>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>>
>> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>>
>> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>>>
>>> That means that only the README and library file remains.
>>>
>>> When the README for Windows keep its length then I don't want to copy
>>> this on the dowload webpage. ;-)
>>>
>>> So, when we put the README for all platforms in their ZIP files then we
>>> can just put a pointer to it on the download webpage and thats it.
>> [orcmid]
>>
>> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
>>
>> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>>
>> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
>>
>> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>>
>>>
>>> To cut a long story short:
>>> I would say yes for a ZIP file for every platform.
>> [ ... ]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
--
Kay Schenk
Apache OpenOffice
----------------------------------------
"Things work out best for those who make
the best of the way things work out."
-- John Wooden
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/10/2016 05:03 AM, schrieb Dennis E. Hamilton:
>
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Tuesday, August 9, 2016 15:26
>> To: dev@openoffice.apache.org
>> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
>> Applying openoffice-4.1.2-patch1 for Windows)
>>
>> Am 08/09/2016 11:12 PM, schrieb Kay Schenk:
>>> [top posting]
>>> I'm in the process of trying to "sync" instructions for Linux32,
>>> Linux64, and MacOSX at the moment. As far as instructions on the
>> actual
>>> HOTFIX page, we need to have just a "general" instruction for ALL zips
>>> that simply says -- "Unzip this package to some folder of your
>> choosing
>>> and read the README that's included." Everything else should be in the
>>> various READMEs for each platform.
>>
>> yes, this shortens the webpage a lot.
>>
>>> I should be done with all edits by this evening for a final review
>>> before zipping and signing.
>>
>> When the ZIP files are ready, I can do the checks for Linux and Windows.
>>
>> Marcus
> [orcmid]
>
> I have a working Windows batch-file script for installing the patch, but I have not updated the documentation yet and I need to do tests on Windows XP to make certain that the script works there too.
>
> The next update for Windows will be version 0.1.0 and be beta level.
>
> There might be an 0.2.0 if the README is changed from .txt to .html to get around line-ending incompatibilities depending on what platform is used for what.
>
> Once those clear, we can look at adjustments for 1.0.0 and general release after a little regression checking.
>
> I suspect the general will happen on Thursday or Friday.
that fits perfectly for my weekend. I can do tests on Windows 10 and
also update the documentation - or at least make some suggestions.
Marcus
>>> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>>>> Branching off the part that is not about the Windows 4.1.2-patch1
>> [TESTING].
>>>>
>>>>> -----Original Message-----
>>>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>>>> Sent: Thursday, August 4, 2016 15:52
>>>>> To: dev@openoffice.apache.org
>>>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>>>
>>>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>>>> [ ... ]
>>>>>>
>>>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>>>
>>>>>> Should we get started on these?
>>>>>
>>>>> it depends what we want that they should contain. The ZIP file for
>>>>> Windows contains a LICENSE and NOTICE file as well as an ASC file
>> for
>>>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>>>> installation. Also the ASC is not necessary as we provide it already
>>>>> (together with MD5 and SHA256) for the whole ZIP file.
>>>> [orcmid]
>>>>
>>>> I think there is a misunderstanding. Two matters:
>>>>
>>>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
>> practice is to include NOTICE as well on binary distributions. The
>> patch qualifies, especially when it is moved to general distribution.
>> It is also easy and harmless to provide.
>>>>
>>>> 2. The reason for preserving the .asc on the shared-library binary
>> is because it authenticates with respect to who produced it and
>> establishes that it has not been modified as supplied in the package (or
>> as the result of some glitch in creation of the Zip). It provides a
>> level of accountability and, also, auditability.
>>>>
>>>> Even though few people will check all of these, they remain possible
>> to be checked. Since this is a matter of security vulnerabilities and
>> involves elevation of privilege to perform, I believe it is important to
>> demonstrate diligence and care, so that users have confidence in this
>> procedure to the extent they are comfortable. Also, if it becomes
>> necessary to troubleshoot a problem with these patch applications, we
>> have the means to authenticate what they are using to ensure there are
>> no counterfeits being offered to users.
>>>>>
>>>>> That means that only the README and library file remains.
>>>>>
>>>>> When the README for Windows keep its length then I don't want to
>> copy
>>>>> this on the dowload webpage. ;-)
>>>>>
>>>>> So, when we put the README for all platforms in their ZIP files then
>> we
>>>>> can just put a pointer to it on the download webpage and thats it.
>>>> [orcmid]
>>>>
>>>> Yes, that seems like a fine idea. The README can be linked the same
>> way the .md5, .sha256, and .asc are linked.
>>>>
>>>> Also, the README may become simpler if we can link to some of the
>> information and not have so much detail in the README text itself. It
>> might even be useful to have an .html README for that matter. But that
>> is all extra. Right now I think we want to get into the testing and see
>> how to smooth what we have.
>>>>
>>>> PS: A friend of mine is looking into the MacOSX situation. He points
>> out that one can use the Finder to do the job without users having to
>> use Terminal sessions. I don't have further information at this time.
>>>>
>>>> PPS: The inclusion of scripts that do the job is also worthy of
>> consideration, perhaps making it unnecessary to build executables. I
>> will be looking at finding a .bat file that works safely for the Windows
>> case. That can make the instructions much shorter :).
>>>>
>>>>>
>>>>> To cut a long story short:
>>>>> I would say yes for a ZIP file for every platform.
>>>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying openoffice-4.1.2-patch1 for Windows)
Posted by "Dennis E. Hamilton" <de...@acm.org>.
> -----Original Message-----
> From: Marcus [mailto:marcus.mail@wtnet.de]
> Sent: Tuesday, August 9, 2016 15:26
> To: dev@openoffice.apache.org
> Subject: Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING]
> Applying openoffice-4.1.2-patch1 for Windows)
>
> Am 08/09/2016 11:12 PM, schrieb Kay Schenk:
> > [top posting]
> > I'm in the process of trying to "sync" instructions for Linux32,
> > Linux64, and MacOSX at the moment. As far as instructions on the
> actual
> > HOTFIX page, we need to have just a "general" instruction for ALL zips
> > that simply says -- "Unzip this package to some folder of your
> choosing
> > and read the README that's included." Everything else should be in the
> > various READMEs for each platform.
>
> yes, this shortens the webpage a lot.
>
> > I should be done with all edits by this evening for a final review
> > before zipping and signing.
>
> When the ZIP files are ready, I can do the checks for Linux and Windows.
>
> Marcus
[orcmid]
I have a working Windows batch-file script for installing the patch, but I have not updated the documentation yet and I need to do tests on Windows XP to make certain that the script works there too.
The next update for Windows will be version 0.1.0 and be beta level.
There might be an 0.2.0 if the README is changed from .txt to .html to get around line-ending incompatibilities depending on what platform is used for what.
Once those clear, we can look at adjustments for 1.0.0 and general release after a little regression checking.
I suspect the general will happen on Thursday or Friday.
>
>
>
> > On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
> >> Branching off the part that is not about the Windows 4.1.2-patch1
> [TESTING].
> >>
> >>> -----Original Message-----
> >>> From: Marcus [mailto:marcus.mail@wtnet.de]
> >>> Sent: Thursday, August 4, 2016 15:52
> >>> To: dev@openoffice.apache.org
> >>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
> >>>
> >>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
> >> [ ... ]
> >>>>
> >>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
> >>>>
> >>>> Should we get started on these?
> >>>
> >>> it depends what we want that they should contain. The ZIP file for
> >>> Windows contains a LICENSE and NOTICE file as well as an ASC file
> for
> >>> the DLL. As it is only a patch IMHO we don't need to provide another
> >>> LICENSE and NOTICE file which is already available in the OpenOffice
> >>> installation. Also the ASC is not necessary as we provide it already
> >>> (together with MD5 and SHA256) for the whole ZIP file.
> >> [orcmid]
> >>
> >> I think there is a misunderstanding. Two matters:
> >>
> >> 1. The use of LICENSE is required by the ALv2 itself, and the ASF
> practice is to include NOTICE as well on binary distributions. The
> patch qualifies, especially when it is moved to general distribution.
> It is also easy and harmless to provide.
> >>
> >> 2. The reason for preserving the .asc on the shared-library binary
> is because it authenticates with respect to who produced it and
> establishes that it has not been modified as supplied in the package (or
> as the result of some glitch in creation of the Zip). It provides a
> level of accountability and, also, auditability.
> >>
> >> Even though few people will check all of these, they remain possible
> to be checked. Since this is a matter of security vulnerabilities and
> involves elevation of privilege to perform, I believe it is important to
> demonstrate diligence and care, so that users have confidence in this
> procedure to the extent they are comfortable. Also, if it becomes
> necessary to troubleshoot a problem with these patch applications, we
> have the means to authenticate what they are using to ensure there are
> no counterfeits being offered to users.
> >>>
> >>> That means that only the README and library file remains.
> >>>
> >>> When the README for Windows keep its length then I don't want to
> copy
> >>> this on the dowload webpage. ;-)
> >>>
> >>> So, when we put the README for all platforms in their ZIP files then
> we
> >>> can just put a pointer to it on the download webpage and thats it.
> >> [orcmid]
> >>
> >> Yes, that seems like a fine idea. The README can be linked the same
> way the .md5, .sha256, and .asc are linked.
> >>
> >> Also, the README may become simpler if we can link to some of the
> information and not have so much detail in the README text itself. It
> might even be useful to have an .html README for that matter. But that
> is all extra. Right now I think we want to get into the testing and see
> how to smooth what we have.
> >>
> >> PS: A friend of mine is looking into the MacOSX situation. He points
> out that one can use the Finder to do the job without users having to
> use Terminal sessions. I don't have further information at this time.
> >>
> >> PPS: The inclusion of scripts that do the job is also worthy of
> consideration, perhaps making it unnecessary to build executables. I
> will be looking at finding a .bat file that works safely for the Windows
> case. That can make the instructions much shorter :).
> >>
> >>>
> >>> To cut a long story short:
> >>> I would say yes for a ZIP file for every platform.
> >> [ ... ]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Marcus <ma...@wtnet.de>.
Am 08/09/2016 11:12 PM, schrieb Kay Schenk:
> [top posting]
> I'm in the process of trying to "sync" instructions for Linux32,
> Linux64, and MacOSX at the moment. As far as instructions on the actual
> HOTFIX page, we need to have just a "general" instruction for ALL zips
> that simply says -- "Unzip this package to some folder of your choosing
> and read the README that's included." Everything else should be in the
> various READMEs for each platform.
yes, this shortens the webpage a lot.
> I should be done with all edits by this evening for a final review
> before zipping and signing.
When the ZIP files are ready, I can do the checks for Linux and Windows.
Marcus
> On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
>> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>>
>>> -----Original Message-----
>>> From: Marcus [mailto:marcus.mail@wtnet.de]
>>> Sent: Thursday, August 4, 2016 15:52
>>> To: dev@openoffice.apache.org
>>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>>
>>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
>> [ ... ]
>>>>
>>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>>
>>>> Should we get started on these?
>>>
>>> it depends what we want that they should contain. The ZIP file for
>>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>>> the DLL. As it is only a patch IMHO we don't need to provide another
>>> LICENSE and NOTICE file which is already available in the OpenOffice
>>> installation. Also the ASC is not necessary as we provide it already
>>> (together with MD5 and SHA256) for the whole ZIP file.
>> [orcmid]
>>
>> I think there is a misunderstanding. Two matters:
>>
>> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>>
>> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>>
>> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>>>
>>> That means that only the README and library file remains.
>>>
>>> When the README for Windows keep its length then I don't want to copy
>>> this on the dowload webpage. ;-)
>>>
>>> So, when we put the README for all platforms in their ZIP files then we
>>> can just put a pointer to it on the download webpage and thats it.
>> [orcmid]
>>
>> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
>>
>> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>>
>> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
>>
>> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>>
>>>
>>> To cut a long story short:
>>> I would say yes for a ZIP file for every platform.
>> [ ... ]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [PACKAGING 4.1.2-patch1 Binaries] (was RE: [TESTING] Applying
openoffice-4.1.2-patch1 for Windows)
Posted by Kay Schenk <ka...@gmail.com>.
[top posting]
I'm in the process of trying to "sync" instructions for Linux32,
Linux64, and MacOSX at the moment. As far as instructions on the actual
HOTFIX page, we need to have just a "general" instruction for ALL zips
that simply says -- "Unzip this package to some folder of your choosing
and read the README that's included." Everything else should be in the
various READMEs for each platform.
I should be done with all edits by this evening for a final review
before zipping and signing.
On 08/05/2016 09:28 AM, Dennis E. Hamilton wrote:
> Branching off the part that is not about the Windows 4.1.2-patch1 [TESTING].
>
>> -----Original Message-----
>> From: Marcus [mailto:marcus.mail@wtnet.de]
>> Sent: Thursday, August 4, 2016 15:52
>> To: dev@openoffice.apache.org
>> Subject: Re: [TESTING] Applying openoffice-4.1.2-patch1 for Windows
>>
>> Am 08/05/2016 12:26 AM, schrieb Kay Schenk:
> [ ... ]
>>>
>>> hmmm...well no zips for Mac, Linux32, or Linux 64 -- yet.
>>>
>>> Should we get started on these?
>>
>> it depends what we want that they should contain. The ZIP file for
>> Windows contains a LICENSE and NOTICE file as well as an ASC file for
>> the DLL. As it is only a patch IMHO we don't need to provide another
>> LICENSE and NOTICE file which is already available in the OpenOffice
>> installation. Also the ASC is not necessary as we provide it already
>> (together with MD5 and SHA256) for the whole ZIP file.
> [orcmid]
>
> I think there is a misunderstanding. Two matters:
>
> 1. The use of LICENSE is required by the ALv2 itself, and the ASF practice is to include NOTICE as well on binary distributions. The patch qualifies, especially when it is moved to general distribution. It is also easy and harmless to provide.
>
> 2. The reason for preserving the .asc on the shared-library binary is because it authenticates with respect to who produced it and establishes that it has not been modified as supplied in the package (or as the result of some glitch in creation of the Zip). It provides a level of accountability and, also, auditability.
>
> Even though few people will check all of these, they remain possible to be checked. Since this is a matter of security vulnerabilities and involves elevation of privilege to perform, I believe it is important to demonstrate diligence and care, so that users have confidence in this procedure to the extent they are comfortable. Also, if it becomes necessary to troubleshoot a problem with these patch applications, we have the means to authenticate what they are using to ensure there are no counterfeits being offered to users.
>>
>> That means that only the README and library file remains.
>>
>> When the README for Windows keep its length then I don't want to copy
>> this on the dowload webpage. ;-)
>>
>> So, when we put the README for all platforms in their ZIP files then we
>> can just put a pointer to it on the download webpage and thats it.
> [orcmid]
>
> Yes, that seems like a fine idea. The README can be linked the same way the .md5, .sha256, and .asc are linked.
>
> Also, the README may become simpler if we can link to some of the information and not have so much detail in the README text itself. It might even be useful to have an .html README for that matter. But that is all extra. Right now I think we want to get into the testing and see how to smooth what we have.
>
> PS: A friend of mine is looking into the MacOSX situation. He points out that one can use the Finder to do the job without users having to use Terminal sessions. I don't have further information at this time.
>
> PPS: The inclusion of scripts that do the job is also worthy of consideration, perhaps making it unnecessary to build executables. I will be looking at finding a .bat file that works safely for the Windows case. That can make the instructions much shorter :).
>
>>
>> To cut a long story short:
>> I would say yes for a ZIP file for every platform.
> [ ... ]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
--------------------------------------------
MzK
"Time spent with cats is never wasted."
-- Sigmund Freud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org