RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Don Lewis [mailto:truck...@apache.org] > Sent: Friday, August 12, 2016 14:09 > To: dev@openoffice.apache.org > Cc: dennis.hamil...@acm.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > On 12 Aug, Dennis E. Hamilton wrote: > > Don, > > > > Having worked through the 4.1.2-patch1 (CVE-2016-1513 remediation) for > > Windows, I learned a few more things about what can be done. [ ... ] > > [orcmid] > > > > There are hashes and a signature for the Zip that contains the patch > > and any procedure. > > > > In the Windows case, the copies of the original distributed tl.dll and > > the patched one each have detached signatures inside the Zip as well. > > No hashes have been added there, on the assumption that checking the > > Zip is good enough. > > That sounds reasonable. Checking the zip before unpacking is important > to prevent attacks against zip itself or to prevent unpacking some other > sort of malware. > > This issue recently came up with FreeBSD, see: > <http://docs.freebsd.org/cgi/mid.cgi?20160810115813.GA86720> [orcmid] Thanks. I admire the demonstration of care, and the quality of the responses where concerns were raised. [ ... ] > > Finally, it is not possible to check dates easily using a .bat script > > on Windows. > > > > This is all resolved in the current 0.1.0 beta of the 4.1.2-patch1 for > > Windows by literally comparing files, rather than checking their dates > > and it is done without depending on signature computation tools being > > available on the machine. > > > > That's how the procedure determines whether the patch file has already > > been applied or not. > > That also sounds reasonable. What tool do you use for the file > comparison? [orcmid] The File Compare utility, FC, is built into all releases of Microsoft Windows. It is basically a standard external command of the cmd.exe console shell. The .bat scripts use it to silently compare and then use the result codes to branch depending on what the level of result code is. - Dennis - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 12 Aug, Dennis E. Hamilton wrote: > Don, > > Having worked through the 4.1.2-patch1 (CVE-2016-1513 remediation) for > Windows, I learned a few more things about what can be done. > > >> -Original Message- >> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] >> Sent: Sunday, July 24, 2016 15:45 >> To: dev@openoffice.apache.org >> Subject: RE: Officially releasing a patch for CVE-2016-1513 >> >> The patched DLL is shipped with an external digital signature. I >> guess we could ask that to be installed alongside it. That would be >> a good tell-tale. >> >> The web site where the patch is downloadable from will have hashes >> for the archive containing the patched library and will also have an >> external signature for that. These are on a secure AOO >> infrastructure site, the best place to retrieve hashes and signature >> files. There is no reason not to have a hash of the library inside >> the downloadable archive for those who, for some reason, cannot check >> the signature but can verify the hash. > [orcmid] > > There are hashes and a signature for the Zip that contains the patch > and any procedure. > > In the Windows case, the copies of the original distributed tl.dll and > the patched one each have detached signatures inside the Zip as well. > No hashes have been added there, on the assumption that checking the > Zip is good enough. That sounds reasonable. Checking the zip before unpacking is important to prevent attacks against zip itself or to prevent unpacking some other sort of malware. This issue recently came up with FreeBSD, see: <http://docs.freebsd.org/cgi/mid.cgi?20160810115813.GA86720> >> >> In the manual procedure, we will ask users to rename the existing >> shared-library before copying in the replacement. This will provide >> a means to revert to the patched library if a regression results. > [orcmid] > > This approach is used. If the patch is applied, the original tl.dll > is renamed to tl.dll.old. This is in the manual procedure and it is > also provided by the script for the automated procedure. > > The script for applying the patch can also be used to determine the > patch is already there. The script for reverting the patch will > determine first whether the patch has been applied. That also sounds reasonable. >> >> There is a difference in file-creation dates and in the size of the >> files as well. The procedure for hotfixing with the patched library >> should provide that information to discourage attempting to patch a >> different release and also make it easier to tell the patch is there. > [orcmid] > > For Windows, it turns out that dates are a problem on files because of > how Windows distinguishes between created and modified. Some > operations change one and not the other in unexpected ways. There are > also differences in this regard between versions of Windows in the > range Windows XP to Windows 10. > > There also seem to be possible issued with the Windows installer > putting new dates on things. > > Finally, it is not possible to check dates easily using a .bat script > on Windows. > > This is all resolved in the current 0.1.0 beta of the 4.1.2-patch1 for > Windows by literally comparing files, rather than checking their dates > and it is done without depending on signature computation tools being > available on the machine. > > That's how the procedure determines whether the patch file has already > been applied or not. That also sounds reasonable. What tool do you use for the file comparison? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
Don, Having worked through the 4.1.2-patch1 (CVE-2016-1513 remediation) for Windows, I learned a few more things about what can be done. > -Original Message- > From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] > Sent: Sunday, July 24, 2016 15:45 > To: dev@openoffice.apache.org > Subject: RE: Officially releasing a patch for CVE-2016-1513 > > The patched DLL is shipped with an external digital signature. I guess > we could ask that to be installed alongside it. That would be a good > tell-tale. > > The web site where the patch is downloadable from will have hashes for > the archive containing the patched library and will also have an > external signature for that. These are on a secure AOO infrastructure > site, the best place to retrieve hashes and signature files. There is > no reason not to have a hash of the library inside the downloadable > archive for those who, for some reason, cannot check the signature but > can verify the hash. [orcmid] There are hashes and a signature for the Zip that contains the patch and any procedure. In the Windows case, the copies of the original distributed tl.dll and the patched one each have detached signatures inside the Zip as well. No hashes have been added there, on the assumption that checking the Zip is good enough. > > In the manual procedure, we will ask users to rename the existing > shared-library before copying in the replacement. This will provide a > means to revert to the patched library if a regression results. [orcmid] This approach is used. If the patch is applied, the original tl.dll is renamed to tl.dll.old. This is in the manual procedure and it is also provided by the script for the automated procedure. The script for applying the patch can also be used to determine the patch is already there. The script for reverting the patch will determine first whether the patch has been applied. > > There is a difference in file-creation dates and in the size of the > files as well. The procedure for hotfixing with the patched library > should provide that information to discourage attempting to patch a > different release and also make it easier to tell the patch is there. [orcmid] For Windows, it turns out that dates are a problem on files because of how Windows distinguishes between created and modified. Some operations change one and not the other in unexpected ways. There are also differences in this regard between versions of Windows in the range Windows XP to Windows 10. There also seem to be possible issued with the Windows installer putting new dates on things. Finally, it is not possible to check dates easily using a .bat script on Windows. This is all resolved in the current 0.1.0 beta of the 4.1.2-patch1 for Windows by literally comparing files, rather than checking their dates and it is done without depending on signature computation tools being available on the machine. That's how the procedure determines whether the patch file has already been applied or not. > > You're right that different builds by others who look to just extract > the shared library will likely end up with a different binary of that > library. For a binary distribution from any origin that has the patch > compiled-in, I would think something like the static string might be > helpful. If we do that in the AOO4121 tag, we'll have to redo the > patched libraries we've already built. I was hoping we could avoid that > and stick with ones we have done some testing on already. > > Is what we're planning enough? > > - Dennis [orcmid] I think this is still good enough. Someone who sees tl.dll.old in there will know there has been a patch. There are more sophisticated scripts that could be developed. That is worth addressing elsewhere on one of these threads. > > > -Original Message- > > From: Don Lewis [mailto:truck...@apache.org] > > Sent: Sunday, July 24, 2016 15:14 > > To: dev@openoffice.apache.org > > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > > > On 24 Jul, Don Lewis wrote: > > > > > At a minimum, we should publish the hash values of buggy and fixed > > > versions of the library. That might not help someone who builds and > > > installs from source since the build not be completely repeatable. > > > For instance the library might contain a timestamp. > > > > Adding a static string "CVE-2016-1513 Fixed" to the source is another > > possibiliy. On *nix, the user/administrator can run: > > strings whatever.so | grep CVE > > and look for the above to verify that the fixed library has been > > installed. Someone would have
Re: Officially releasing a patch for CVE-2016-1513
On 08/02/2016 10:04 AM, Marcus wrote: > Am 08/02/2016 05:28 PM, schrieb Kay Schenk: >> >> >> On 08/01/2016 07:38 PM, Dennis E. Hamilton wrote: >>> >>> >>>> -Original Message- >>>> From: Kay Schenk [mailto:kay.sch...@gmail.com] >>>> Sent: Monday, August 1, 2016 15:43 >>>> To: dev@openoffice.apache.org >>>> Subject: Re: Officially releasing a patch for CVE-2016-1513 >>>> >>>> >>>> On 07/31/2016 05:17 PM, Dennis E. Hamilton wrote: >>>>> >>>>> >>>>>> -Original Message- >>>>>> From: Kay sch...@apache.org [mailto:ksch...@apache.org] >>>>>> Sent: Sunday, July 31, 2016 14:42 >>>>>> To: dev@openoffice.apache.org >>>>>> Subject: Re: Officially releasing a patch for CVE-2016-1513 >>>>>> >>>>>> OK, I think I'm done with the LInux64 bit area as well. >>>>>> >>>>>> And see below >>>>>> >>>>>> >>>>>> On 07/31/2016 01:10 PM, Marcus wrote: >>>>> [ ... ] >>>>>>> I'm preparing the hotfix webpage. For this I've some questions: >>>>>>> >>>>>>> 1. Do we want to provide zip files for every platform or just single >>>>>>> files for the library and other files? >>>>>> >>>>>> H... I assumed we would just be point people directly at >>>>>> /dist/release/openoffice/patches. >>>>>> (Right now, these are in /dist/dev/openoffice/patches.) >>>>>> >>>>>> It would be easiest to just setup the hotfix page with three links >>>> per >>>>>> distro. >>>>>> >>>>>> Linux32 >>>>>> * link to Linux32.README >>>>>> * link to linux32 libtl.so >>>>>> * link to linux32 libtl.so.asc (sig) >>>>>> >>>>>> etc. >>>>>> >>>>>> If not, the READMEs I wrote will need to change. >>>>> [orcmid] >>>>> >>>>> I recommend there should be single-file (e.g., Zip) distributions, >>>> just like all other binaries. That gives just one thing to download. >>>> The MD5, SHA512, and ASC signatures should be on the whole package and >>>> stay in the dev/ and release/ folders, just as they are on download >>>> pages. (The ASC signatures on the individual library-file binaries >>>> should be inside the package.) I suspect, on the dev/ side, we might >>>> need copies of the READMEs alongside the archives, and revised more >>>> regularly, >>>> >>>> I was Ok up to this statement. Are you saying INCLUDE the readmes in >>>> the >>>> zip package but leave them outside of where they now are? If we want >>>> signed zip files, can't we just leave the files we have now in: >>>> >>>> https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ >>>> >>>> >>>> but zip them up as well, inlcuding the READMEs? >>>> Or, are you saying at distribution time, remove the libraries and their >>>> sigs Btu leave the README files? >>>> We have these in their own labeled area -- 4.1.2-patch1 -- so I don't >>>> see a problem with just leaving everything there. >>>> >>> [orcmid] >>> >>> I'll do what I mean by example when I upload the Windows case by >>> tomorrow morning, at the latest. >>> >>> Then it will be easier to talk about it. >>> >>> - Dennis >>> >> >> OK, great...it's looks like we are still lacking a MacOSX README. Any >> volunteers? >> Even if you can't or don't want to commit to: >> https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ >> >> Please send to this list as a ".txt" attachment and we should be able to >> receive it. >> >> Thanks in advance for your help. > > OK, I'll give you (the Mac experts) a starting point: > > 1. Make sure that OpenOffice is not running. > 2. Open a terminal and unpack the downloaded file (e.g., with Archive > Utility or WinZip Mac Edition) to an easily locatable path. > 3. Open the Finder App - or another file manager of your choice. > 4. Locate the installation path of OpenOffice (e.g., > "/A
Re: Officially releasing a patch for CVE-2016-1513
Am 08/02/2016 05:28 PM, schrieb Kay Schenk: On 08/01/2016 07:38 PM, Dennis E. Hamilton wrote: -Original Message- From: Kay Schenk [mailto:kay.sch...@gmail.com] Sent: Monday, August 1, 2016 15:43 To: dev@openoffice.apache.org Subject: Re: Officially releasing a patch for CVE-2016-1513 On 07/31/2016 05:17 PM, Dennis E. Hamilton wrote: -Original Message- From: Kay sch...@apache.org [mailto:ksch...@apache.org] Sent: Sunday, July 31, 2016 14:42 To: dev@openoffice.apache.org Subject: Re: Officially releasing a patch for CVE-2016-1513 OK, I think I'm done with the LInux64 bit area as well. And see below On 07/31/2016 01:10 PM, Marcus wrote: [ ... ] I'm preparing the hotfix webpage. For this I've some questions: 1. Do we want to provide zip files for every platform or just single files for the library and other files? H... I assumed we would just be point people directly at /dist/release/openoffice/patches. (Right now, these are in /dist/dev/openoffice/patches.) It would be easiest to just setup the hotfix page with three links per distro. Linux32 * link to Linux32.README * link to linux32 libtl.so * link to linux32 libtl.so.asc (sig) etc. If not, the READMEs I wrote will need to change. [orcmid] I recommend there should be single-file (e.g., Zip) distributions, just like all other binaries. That gives just one thing to download. The MD5, SHA512, and ASC signatures should be on the whole package and stay in the dev/ and release/ folders, just as they are on download pages. (The ASC signatures on the individual library-file binaries should be inside the package.) I suspect, on the dev/ side, we might need copies of the READMEs alongside the archives, and revised more regularly, I was Ok up to this statement. Are you saying INCLUDE the readmes in the zip package but leave them outside of where they now are? If we want signed zip files, can't we just leave the files we have now in: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ but zip them up as well, inlcuding the READMEs? Or, are you saying at distribution time, remove the libraries and their sigs Btu leave the README files? We have these in their own labeled area -- 4.1.2-patch1 -- so I don't see a problem with just leaving everything there. [orcmid] I'll do what I mean by example when I upload the Windows case by tomorrow morning, at the latest. Then it will be easier to talk about it. - Dennis OK, great...it's looks like we are still lacking a MacOSX README. Any volunteers? Even if you can't or don't want to commit to: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ Please send to this list as a ".txt" attachment and we should be able to receive it. Thanks in advance for your help. OK, I'll give you (the Mac experts) a starting point: 1. Make sure that OpenOffice is not running. 2. Open a terminal and unpack the downloaded file (e.g., with Archive Utility or WinZip Mac Edition) to an easily locatable path. 3. Open the Finder App - or another file manager of your choice. 4. Locate the installation path of OpenOffice (e.g., "/Applications/Utilities/OpenOffice4/program/"). 5. Rename the old file "libtl.dylib" to "libtl.dylib.original" to keep a backup. 6. Copy the new file from the unpacked Zip file to the installation path (e.g, "/Desktop/libtl.dylib" --> "/Applications/Utilities/OpenOffice4/program/"). Yes, it's not complete and maybe a bit incorrect. But better this than nothing. :-P Marcus so they can be reviewed and revised easily as we get QA and trial use. When we move over to release/ we might want to do the same, even though the README is in the archive, so that people can read it without downloading the package. Finally, please use README.txt, etc., so that line-ending adjustments will happen properly when folks move these in and out of SVN and also out of archive files. This will also help browsers when folks retrieve these directly from the repository. PS: If we are concerned about the README.txt outside of the archive being authenticated, it can have an embedded PGP signature. (Then the final archive-internal one would be a copy of the signed README.txt -- no biggie, nice chain of custody). [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 08/01/2016 07:38 PM, Dennis E. Hamilton wrote: > > >> -Original Message- >> From: Kay Schenk [mailto:kay.sch...@gmail.com] >> Sent: Monday, August 1, 2016 15:43 >> To: dev@openoffice.apache.org >> Subject: Re: Officially releasing a patch for CVE-2016-1513 >> >> >> On 07/31/2016 05:17 PM, Dennis E. Hamilton wrote: >>> >>> >>>> -Original Message- >>>> From: Kay sch...@apache.org [mailto:ksch...@apache.org] >>>> Sent: Sunday, July 31, 2016 14:42 >>>> To: dev@openoffice.apache.org >>>> Subject: Re: Officially releasing a patch for CVE-2016-1513 >>>> >>>> OK, I think I'm done with the LInux64 bit area as well. >>>> >>>> And see below >>>> >>>> >>>> On 07/31/2016 01:10 PM, Marcus wrote: >>> [ ... ] >>>>> I'm preparing the hotfix webpage. For this I've some questions: >>>>> >>>>> 1. Do we want to provide zip files for every platform or just single >>>>> files for the library and other files? >>>> >>>> H... I assumed we would just be point people directly at >>>> /dist/release/openoffice/patches. >>>> (Right now, these are in /dist/dev/openoffice/patches.) >>>> >>>> It would be easiest to just setup the hotfix page with three links >> per >>>> distro. >>>> >>>> Linux32 >>>> * link to Linux32.README >>>> * link to linux32 libtl.so >>>> * link to linux32 libtl.so.asc (sig) >>>> >>>> etc. >>>> >>>> If not, the READMEs I wrote will need to change. >>> [orcmid] >>> >>> I recommend there should be single-file (e.g., Zip) distributions, >> just like all other binaries. That gives just one thing to download. >> The MD5, SHA512, and ASC signatures should be on the whole package and >> stay in the dev/ and release/ folders, just as they are on download >> pages. (The ASC signatures on the individual library-file binaries >> should be inside the package.) I suspect, on the dev/ side, we might >> need copies of the READMEs alongside the archives, and revised more >> regularly, >> >> I was Ok up to this statement. Are you saying INCLUDE the readmes in the >> zip package but leave them outside of where they now are? If we want >> signed zip files, can't we just leave the files we have now in: >> >> https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ >> >> but zip them up as well, inlcuding the READMEs? >> Or, are you saying at distribution time, remove the libraries and their >> sigs Btu leave the README files? >> We have these in their own labeled area -- 4.1.2-patch1 -- so I don't >> see a problem with just leaving everything there. >> > [orcmid] > > I'll do what I mean by example when I upload the Windows case by tomorrow > morning, at the latest. > > Then it will be easier to talk about it. > > - Dennis > OK, great...it's looks like we are still lacking a MacOSX README. Any volunteers? Even if you can't or don't want to commit to: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ Please send to this list as a ".txt" attachment and we should be able to receive it. Thanks in advance for your help. >>> so they can be reviewed and revised easily as we get QA and trial use. >> When we move over to release/ we might want to do the same, even though >> the README is in the archive, so that people can read it without >> downloading the package. >>> >>> Finally, please use README.txt, etc., so that line-ending adjustments >> will happen properly when folks move these in and out of SVN and also >> out of archive files. This will also help browsers when folks retrieve >> these directly from the repository. >>> >>> PS: If we are concerned about the README.txt outside of the archive >> being authenticated, it can have an embedded PGP signature. (Then the >> final archive-internal one would be a copy of the signed README.txt -- >> no biggie, nice chain of custody). >>> >>> [ ... ] >>> -- MzK "Time spent with cats is never wasted." -- Sigmund Freud - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Kay Schenk [mailto:kay.sch...@gmail.com] > Sent: Monday, August 1, 2016 15:43 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > > On 07/31/2016 05:17 PM, Dennis E. Hamilton wrote: > > > > > >> -Original Message- > >> From: Kay sch...@apache.org [mailto:ksch...@apache.org] > >> Sent: Sunday, July 31, 2016 14:42 > >> To: dev@openoffice.apache.org > >> Subject: Re: Officially releasing a patch for CVE-2016-1513 > >> > >> OK, I think I'm done with the LInux64 bit area as well. > >> > >> And see below > >> > >> > >> On 07/31/2016 01:10 PM, Marcus wrote: > > [ ... ] > >>> I'm preparing the hotfix webpage. For this I've some questions: > >>> > >>> 1. Do we want to provide zip files for every platform or just single > >>> files for the library and other files? > >> > >> H... I assumed we would just be point people directly at > >> /dist/release/openoffice/patches. > >> (Right now, these are in /dist/dev/openoffice/patches.) > >> > >> It would be easiest to just setup the hotfix page with three links > per > >> distro. > >> > >> Linux32 > >> * link to Linux32.README > >> * link to linux32 libtl.so > >> * link to linux32 libtl.so.asc (sig) > >> > >> etc. > >> > >> If not, the READMEs I wrote will need to change. > > [orcmid] > > > > I recommend there should be single-file (e.g., Zip) distributions, > just like all other binaries. That gives just one thing to download. > The MD5, SHA512, and ASC signatures should be on the whole package and > stay in the dev/ and release/ folders, just as they are on download > pages. (The ASC signatures on the individual library-file binaries > should be inside the package.) I suspect, on the dev/ side, we might > need copies of the READMEs alongside the archives, and revised more > regularly, > > I was Ok up to this statement. Are you saying INCLUDE the readmes in the > zip package but leave them outside of where they now are? If we want > signed zip files, can't we just leave the files we have now in: > > https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ > > but zip them up as well, inlcuding the READMEs? > Or, are you saying at distribution time, remove the libraries and their > sigs Btu leave the README files? > We have these in their own labeled area -- 4.1.2-patch1 -- so I don't > see a problem with just leaving everything there. > [orcmid] I'll do what I mean by example when I upload the Windows case by tomorrow morning, at the latest. Then it will be easier to talk about it. - Dennis > > so they can be reviewed and revised easily as we get QA and trial use. > When we move over to release/ we might want to do the same, even though > the README is in the archive, so that people can read it without > downloading the package. > > > > Finally, please use README.txt, etc., so that line-ending adjustments > will happen properly when folks move these in and out of SVN and also > out of archive files. This will also help browsers when folks retrieve > these directly from the repository. > > > > PS: If we are concerned about the README.txt outside of the archive > being authenticated, it can have an embedded PGP signature. (Then the > final archive-internal one would be a copy of the signed README.txt -- > no biggie, nice chain of custody). > > > > [ ... ] > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > -- > > MzK > > "Time spent with cats is never wasted." >-- Sigmund Freud > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 07/31/2016 05:17 PM, Dennis E. Hamilton wrote: > > >> -Original Message- >> From: Kay sch...@apache.org [mailto:ksch...@apache.org] >> Sent: Sunday, July 31, 2016 14:42 >> To: dev@openoffice.apache.org >> Subject: Re: Officially releasing a patch for CVE-2016-1513 >> >> OK, I think I'm done with the LInux64 bit area as well. >> >> And see below >> >> >> On 07/31/2016 01:10 PM, Marcus wrote: > [ ... ] >>> I'm preparing the hotfix webpage. For this I've some questions: >>> >>> 1. Do we want to provide zip files for every platform or just single >>> files for the library and other files? >> >> H... I assumed we would just be point people directly at >> /dist/release/openoffice/patches. >> (Right now, these are in /dist/dev/openoffice/patches.) >> >> It would be easiest to just setup the hotfix page with three links per >> distro. >> >> Linux32 >> * link to Linux32.README >> * link to linux32 libtl.so >> * link to linux32 libtl.so.asc (sig) >> >> etc. >> >> If not, the READMEs I wrote will need to change. > [orcmid] > > I recommend there should be single-file (e.g., Zip) distributions, just like > all other binaries. That gives just one thing to download. The MD5, SHA512, > and ASC signatures should be on the whole package and stay in the dev/ and > release/ folders, just as they are on download pages. (The ASC signatures on > the individual library-file binaries should be inside the package.) I > suspect, on the dev/ side, we might need copies of the READMEs alongside the > archives, and revised more regularly, I was Ok up to this statement. Are you saying INCLUDE the readmes in the zip package but leave them outside of where they now are? If we want signed zip files, can't we just leave the files we have now in: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ but zip them up as well, inlcuding the READMEs? Or, are you saying at distribution time, remove the libraries and their sigs Btu leave the README files? We have these in their own labeled area -- 4.1.2-patch1 -- so I don't see a problem with just leaving everything there. > so they can be reviewed and revised easily as we get QA and trial use. When > we move over to release/ we might want to do the same, even though the README > is in the archive, so that people can read it without downloading the package. > > Finally, please use README.txt, etc., so that line-ending adjustments will > happen properly when folks move these in and out of SVN and also out of > archive files. This will also help browsers when folks retrieve these > directly from the repository. > > PS: If we are concerned about the README.txt outside of the archive being > authenticated, it can have an embedded PGP signature. (Then the final > archive-internal one would be a copy of the signed README.txt -- no biggie, > nice chain of custody). > > [ ... ] > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- MzK "Time spent with cats is never wasted." -- Sigmund Freud - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Patricia Shanahan [mailto:p...@acm.org] > Sent: Sunday, July 31, 2016 21:37 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > > > On 7/31/2016 5:17 PM, Dennis E. Hamilton wrote: > > > > > >> -Original Message- > >> From: Kay sch...@apache.org [mailto:ksch...@apache.org] > >> Sent: Sunday, July 31, 2016 14:42 > >> To: dev@openoffice.apache.org > >> Subject: Re: Officially releasing a patch for CVE-2016-1513 > >> > >> OK, I think I'm done with the LInux64 bit area as well. > >> > >> And see below > >> > >> > >> On 07/31/2016 01:10 PM, Marcus wrote: > > [ ... ] > >>> I'm preparing the hotfix webpage. For this I've some questions: > >>> > >>> 1. Do we want to provide zip files for every platform or just single > >>> files for the library and other files? > >> > >> H... I assumed we would just be point people directly at > >> /dist/release/openoffice/patches. > >> (Right now, these are in /dist/dev/openoffice/patches.) > >> > >> It would be easiest to just setup the hotfix page with three links > per > >> distro. > >> > >> Linux32 > >> * link to Linux32.README > >> * link to linux32 libtl.so > >> * link to linux32 libtl.so.asc (sig) > >> > >> etc. > >> > >> If not, the READMEs I wrote will need to change. > > [orcmid] > > > > I recommend there should be single-file (e.g., Zip) distributions, > just like all other binaries. That gives just one thing to download. > The MD5, SHA512, and ASC signatures should be on the whole package and > stay in the dev/ and release/ folders, just as they are on download > pages. (The ASC signatures on the individual library-file binaries > should be inside the package.) I suspect, on the dev/ side, we might > need copies of the READMEs alongside the archives, and revised more > regularly, so they can be reviewed and revised easily as we get QA and > trial use. When we move over to release/ we might want to do the same, > even though the README is in the archive, so that people can read it > without downloading the package. > > > > Finally, please use README.txt, etc., so that line-ending adjustments > will happen properly when folks move these in and out of SVN and also > out of archive files. This will also help browsers when folks retrieve > these directly from the repository. > > > > PS: If we are concerned about the README.txt outside of the archive > being authenticated, it can have an embedded PGP signature. (Then the > final archive-internal one would be a copy of the signed README.txt -- > no biggie, nice chain of custody). > > > > [ ... ] > > For the end user, this is incredibly, painfully more complicated than > downloading and installing a new version. [orcmid] Indeed it is. I think there is no question how daunting this might be and we must be very careful with this. The README.txt cannot be comprehensive for what a casual user might require, and a power user of OpenOffice might not be much of a power user of Windows. That has to be taken into account. Is there a suggestion lurking in the observation? - Dennis > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Patricia Shanahan wrote: For the end user, this is incredibly, painfully more complicated than downloading and installing a new version. It is. We must make clear that this is a "convenience" update made available to power users, but at the same time state clearly that this (non-critical) vulnerability will be fixed in the next release. Now the patch is applied to all active branches, so whatever we release will surely contain the fix. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 7/31/2016 5:17 PM, Dennis E. Hamilton wrote: -Original Message- From: Kay sch...@apache.org [mailto:ksch...@apache.org] Sent: Sunday, July 31, 2016 14:42 To: dev@openoffice.apache.org Subject: Re: Officially releasing a patch for CVE-2016-1513 OK, I think I'm done with the LInux64 bit area as well. And see below On 07/31/2016 01:10 PM, Marcus wrote: [ ... ] I'm preparing the hotfix webpage. For this I've some questions: 1. Do we want to provide zip files for every platform or just single files for the library and other files? H... I assumed we would just be point people directly at /dist/release/openoffice/patches. (Right now, these are in /dist/dev/openoffice/patches.) It would be easiest to just setup the hotfix page with three links per distro. Linux32 * link to Linux32.README * link to linux32 libtl.so * link to linux32 libtl.so.asc (sig) etc. If not, the READMEs I wrote will need to change. [orcmid] I recommend there should be single-file (e.g., Zip) distributions, just like all other binaries. That gives just one thing to download. The MD5, SHA512, and ASC signatures should be on the whole package and stay in the dev/ and release/ folders, just as they are on download pages. (The ASC signatures on the individual library-file binaries should be inside the package.) I suspect, on the dev/ side, we might need copies of the READMEs alongside the archives, and revised more regularly, so they can be reviewed and revised easily as we get QA and trial use. When we move over to release/ we might want to do the same, even though the README is in the archive, so that people can read it without downloading the package. Finally, please use README.txt, etc., so that line-ending adjustments will happen properly when folks move these in and out of SVN and also out of archive files. This will also help browsers when folks retrieve these directly from the repository. PS: If we are concerned about the README.txt outside of the archive being authenticated, it can have an embedded PGP signature. (Then the final archive-internal one would be a copy of the signed README.txt -- no biggie, nice chain of custody). [ ... ] For the end user, this is incredibly, painfully more complicated than downloading and installing a new version. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Kay sch...@apache.org [mailto:ksch...@apache.org] > Sent: Sunday, July 31, 2016 14:42 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > OK, I think I'm done with the LInux64 bit area as well. > > And see below > > > On 07/31/2016 01:10 PM, Marcus wrote: [ ... ] > > I'm preparing the hotfix webpage. For this I've some questions: > > > > 1. Do we want to provide zip files for every platform or just single > > files for the library and other files? > > H... I assumed we would just be point people directly at > /dist/release/openoffice/patches. > (Right now, these are in /dist/dev/openoffice/patches.) > > It would be easiest to just setup the hotfix page with three links per > distro. > > Linux32 > * link to Linux32.README > * link to linux32 libtl.so > * link to linux32 libtl.so.asc (sig) > > etc. > > If not, the READMEs I wrote will need to change. [orcmid] I recommend there should be single-file (e.g., Zip) distributions, just like all other binaries. That gives just one thing to download. The MD5, SHA512, and ASC signatures should be on the whole package and stay in the dev/ and release/ folders, just as they are on download pages. (The ASC signatures on the individual library-file binaries should be inside the package.) I suspect, on the dev/ side, we might need copies of the READMEs alongside the archives, and revised more regularly, so they can be reviewed and revised easily as we get QA and trial use. When we move over to release/ we might want to do the same, even though the README is in the archive, so that people can read it without downloading the package. Finally, please use README.txt, etc., so that line-ending adjustments will happen properly when folks move these in and out of SVN and also out of archive files. This will also help browsers when folks retrieve these directly from the repository. PS: If we are concerned about the README.txt outside of the archive being authenticated, it can have an embedded PGP signature. (Then the final archive-internal one would be a copy of the signed README.txt -- no biggie, nice chain of custody). [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
OK, I think I'm done with the LInux64 bit area as well. And see below On 07/31/2016 01:10 PM, Marcus wrote: > Am 07/31/2016 08:52 PM, schrieb Kay Schenk: >> Well...I didn't see this message before I got started and I just >> finished with Linux32 and used Ariel's patch for this. Of course it can >> be changed if desired. File size wise, Ariel's patch seemed more in >> keeping with what I have. You can see what I put on the commit for this. >> I don't want to get in the middle of whose patches to use, so someone >> else can re-commit and change this if they like. >> >> I need some review on the VERY large README I put out there for Linux32. >> I know some Linux folks are not comfortable with the command line, so, >> it turned out larger than I had originally anticipated. >> If the linux64 stuff is similar, I'll just basically do the same for it. >> I don't run on Linux64 so I can't do any comparisons between file sizes >> provided by Carl vs Ariel. > > I don't think that there won't be any differences when I look at your > instructions in the README. > >> And finally, I put out the MacOSX patch already but have NO instructions >> because I don't know Mac. Someone else will need to write and commit the MacOSX instructions. >> >> I won't be doing anything with the Windows area at all, leaving that to >> someone else. >> >> In summary, I will finish up doing the same for Linux64 today in a while. >> >> I won't have time to work on any more of this until Tuesday at the >> earliest. > > I'm preparing the hotfix webpage. For this I've some questions: > > 1. Do we want to provide zip files for every platform or just single > files for the library and other files? H... I assumed we would just be point people directly at /dist/release/openoffice/patches. (Right now, these are in /dist/dev/openoffice/patches.) It would be easiest to just setup the hotfix page with three links per distro. Linux32 * link to Linux32.README * link to linux32 libtl.so * link to linux32 libtl.so.asc (sig) etc. If not, the READMEs I wrote will need to change. Others may have a different opinion. > > 2. Can we add ASC, MD5, SHA256 files for every library (or zip) file? The developer sigs provided with the patches should be sufficient. maybe? Well this is why I was concerned about matching file sizes with what people already had. Hopefully, if some are a bit off, it won't be a deterrent for people to apply these. > > 3. Is this the final URL or just for our testing before moving to the > official URL? See above -- ? > > Thanks > > Marcus > > > >> On 07/31/2016 10:21 AM, Dennis E. Hamilton wrote: >>> I would prefer that we use Ariel's for the Mac and keep the other >>> Linux ones since those have been accounted for as having been put >>> through the confirmation process and smoke testing. I would like to >>> recognize as many of the contributors as possible. I used Carl's 64-bit patch. >>> >>> Kay, if you are going to do the uploads of the initial ones for the >>> dev/openoffice/4.1.2-patch1/binary/ area, let me know. I will not do >>> anything about added documentation for any of them until they are in >>> the SVN. >>> >>> If you do not, I will do so, with some initial documentation. >>> >>> - Dennis >>> >>>> -Original Message- >>>> From: Andrea Pescetti [mailto:pesce...@apache.org] >>>> Sent: Sunday, July 31, 2016 05:26 >>>> To: dev@openoffice.apache.org >>>> Subject: Re: Officially releasing a patch for CVE-2016-1513 >>>> >>>> On 30/07/2016 Kay Schenk wrote: >>>>> duplicate fixed >>>>> libraries for Linux-32, and Linux-64 based on submissions from Carl, >>>>> Damjan, and Ariel. I'd be happy to move these somewhere in the next >>>> day or >>>>> so, but I don't know what versions we want to use. >>>> >>>> Ariel's were built on a CentOS 5 system, so equivalent to the one we >>>> used for 4.1.2; I would thus tend to prefer those (while thanking all >>>> the others for providing builds!). > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Am 07/31/2016 08:52 PM, schrieb Kay Schenk: Well...I didn't see this message before I got started and I just finished with Linux32 and used Ariel's patch for this. Of course it can be changed if desired. File size wise, Ariel's patch seemed more in keeping with what I have. You can see what I put on the commit for this. I don't want to get in the middle of whose patches to use, so someone else can re-commit and change this if they like. I need some review on the VERY large README I put out there for Linux32. I know some Linux folks are not comfortable with the command line, so, it turned out larger than I had originally anticipated. If the linux64 stuff is similar, I'll just basically do the same for it. I don't run on Linux64 so I can't do any comparisons between file sizes provided by Carl vs Ariel. I don't think that there won't be any differences when I look at your instructions in the README. And finally, I put out the MacOSX patch already but have NO instructions because I don't know Mac. I won't be doing anything with the Windows area at all, leaving that to someone else. In summary, I will finish up doing the same for Linux64 today in a while. I won't have time to work on any more of this until Tuesday at the earliest. I'm preparing the hotfix webpage. For this I've some questions: 1. Do we want to provide zip files for every platform or just single files for the library and other files? 2. Can we add ASC, MD5, SHA256 files for every library (or zip) file? 3. Is this the final URL or just for our testing before moving to the official URL? Thanks Marcus On 07/31/2016 10:21 AM, Dennis E. Hamilton wrote: I would prefer that we use Ariel's for the Mac and keep the other Linux ones since those have been accounted for as having been put through the confirmation process and smoke testing. I would like to recognize as many of the contributors as possible. Kay, if you are going to do the uploads of the initial ones for the dev/openoffice/4.1.2-patch1/binary/ area, let me know. I will not do anything about added documentation for any of them until they are in the SVN. If you do not, I will do so, with some initial documentation. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Sunday, July 31, 2016 05:26 To: dev@openoffice.apache.org Subject: Re: Officially releasing a patch for CVE-2016-1513 On 30/07/2016 Kay Schenk wrote: duplicate fixed libraries for Linux-32, and Linux-64 based on submissions from Carl, Damjan, and Ariel. I'd be happy to move these somewhere in the next day or so, but I don't know what versions we want to use. Ariel's were built on a CentOS 5 system, so equivalent to the one we used for 4.1.2; I would thus tend to prefer those (while thanking all the others for providing builds!). - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Kay Schenk [mailto:kay.sch...@gmail.com] > Sent: Sunday, July 31, 2016 11:53 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 [ ... ] > > I won't be doing anything with the Windows area at all, leaving that to > someone else. [orcmid] Yes, please leave the Windows case to me. - Dennis > > In summary, I will finish up doing the same for Linux64 today in a > while. > > I won't have time to work on any more of this until Tuesday at the > earliest. > > > On 07/31/2016 10:21 AM, Dennis E. Hamilton wrote: > > I would prefer that we use Ariel's for the Mac and keep the other > Linux ones since those have been accounted for as having been put > through the confirmation process and smoke testing. I would like to > recognize as many of the contributors as possible. > > > > Kay, if you are going to do the uploads of the initial ones for the > dev/openoffice/4.1.2-patch1/binary/ area, let me know. I will not do > anything about added documentation for any of them until they are in the > SVN. > > > > If you do not, I will do so, with some initial documentation. > > > > - Dennis [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Well...I didn't see this message before I got started and I just finished with Linux32 and used Ariel's patch for this. Of course it can be changed if desired. File size wise, Ariel's patch seemed more in keeping with what I have. You can see what I put on the commit for this. I don't want to get in the middle of whose patches to use, so someone else can re-commit and change this if they like. I need some review on the VERY large README I put out there for Linux32. I know some Linux folks are not comfortable with the command line, so, it turned out larger than I had originally anticipated. If the linux64 stuff is similar, I'll just basically do the same for it. I don't run on Linux64 so I can't do any comparisons between file sizes provided by Carl vs Ariel. And finally, I put out the MacOSX patch already but have NO instructions because I don't know Mac. I won't be doing anything with the Windows area at all, leaving that to someone else. In summary, I will finish up doing the same for Linux64 today in a while. I won't have time to work on any more of this until Tuesday at the earliest. On 07/31/2016 10:21 AM, Dennis E. Hamilton wrote: > I would prefer that we use Ariel's for the Mac and keep the other Linux ones > since those have been accounted for as having been put through the > confirmation process and smoke testing. I would like to recognize as many of > the contributors as possible. > > Kay, if you are going to do the uploads of the initial ones for the > dev/openoffice/4.1.2-patch1/binary/ area, let me know. I will not do > anything about added documentation for any of them until they are in the SVN. > > > If you do not, I will do so, with some initial documentation. > > - Dennis > >> -Original Message- >> From: Andrea Pescetti [mailto:pesce...@apache.org] >> Sent: Sunday, July 31, 2016 05:26 >> To: dev@openoffice.apache.org >> Subject: Re: Officially releasing a patch for CVE-2016-1513 >> >> On 30/07/2016 Kay Schenk wrote: >>> duplicate fixed >>> libraries for Linux-32, and Linux-64 based on submissions from Carl, >>> Damjan, and Ariel. I'd be happy to move these somewhere in the next >> day or >>> so, but I don't know what versions we want to use. >> >> Ariel's were built on a CentOS 5 system, so equivalent to the one we >> used for 4.1.2; I would thus tend to prefer those (while thanking all >> the others for providing builds!). >> >> Regards, >>Andrea. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > -- MzK "Time spent with cats is never wasted." -- Sigmund Freud - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
I would prefer that we use Ariel's for the Mac and keep the other Linux ones since those have been accounted for as having been put through the confirmation process and smoke testing. I would like to recognize as many of the contributors as possible. Kay, if you are going to do the uploads of the initial ones for the dev/openoffice/4.1.2-patch1/binary/ area, let me know. I will not do anything about added documentation for any of them until they are in the SVN. If you do not, I will do so, with some initial documentation. - Dennis > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Sunday, July 31, 2016 05:26 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > On 30/07/2016 Kay Schenk wrote: > > duplicate fixed > > libraries for Linux-32, and Linux-64 based on submissions from Carl, > > Damjan, and Ariel. I'd be happy to move these somewhere in the next > day or > > so, but I don't know what versions we want to use. > > Ariel's were built on a CentOS 5 system, so equivalent to the one we > used for 4.1.2; I would thus tend to prefer those (while thanking all > the others for providing builds!). > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 07/31/2016 05:55 AM, Carl Marcum wrote: > On 07/31/2016 08:25 AM, Andrea Pescetti wrote: >> On 30/07/2016 Kay Schenk wrote: >>> duplicate fixed >>> libraries for Linux-32, and Linux-64 based on submissions from Carl, >>> Damjan, and Ariel. I'd be happy to move these somewhere in the next >>> day or >>> so, but I don't know what versions we want to use. >> >> Ariel's were built on a CentOS 5 system, so equivalent to the one we >> used for 4.1.2; I would thus tend to prefer those (while thanking all >> the others for providing builds!). > > That's okay with me. > > Carl > >> >> Regards, >> Andrea. OK, thanks for the feedback. OK, I will use Ariel's patches and be moving the 2 Linux patches to: https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/binaries/ in just a bit with some instructions for each -- 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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 07/31/2016 08:25 AM, Andrea Pescetti wrote: On 30/07/2016 Kay Schenk wrote: duplicate fixed libraries for Linux-32, and Linux-64 based on submissions from Carl, Damjan, and Ariel. I'd be happy to move these somewhere in the next day or so, but I don't know what versions we want to use. Ariel's were built on a CentOS 5 system, so equivalent to the one we used for 4.1.2; I would thus tend to prefer those (while thanking all the others for providing builds!). That's okay with me. Carl Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 30/07/2016 Kay Schenk wrote: duplicate fixed libraries for Linux-32, and Linux-64 based on submissions from Carl, Damjan, and Ariel. I'd be happy to move these somewhere in the next day or so, but I don't know what versions we want to use. Ariel's were built on a CentOS 5 system, so equivalent to the one we used for 4.1.2; I would thus tend to prefer those (while thanking all the others for providing builds!). Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Hello, all -- I've been reviewing the replacement libraries submitted by Carl, Damjan, Pat, and Ariel for valid sigs. All look good.. We now have duplicate fixed libraries for Linux-32, and Linux-64 based on submissions from Carl, Damjan, and Ariel. I'd be happy to move these somewhere in the next day or so, but I don't know what versions we want to use. We have only single submissions for MacOSX and Windows. So, guidance needed. Thanks. On Sat, Jul 30, 2016 at 12:15 PM, Dennis E. Hamilton < dennis.hamil...@acm.org> wrote: > > > > -Original Message- > > From: Andrea Pescetti [mailto:pesce...@apache.org] > > Sent: Saturday, July 30, 2016 11:09 > > To: dev@openoffice.apache.org > > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > > > Dennis E. Hamilton wrote: > > > I would like to remove those three. > > > > Sure, feel free to. As I wrote, they were meant as backup solutions in > > case we had issues with the patch-only package. > [orcmid] > > Done > > > > > > I have reviewed apache-openoffice-4.1.2-patch1.zip ... > > > I think this is good enough to go with. > > > > Perfect, then feel free to start a vote when you wish. > [orcmid] > > Will do. Sometime in next 36 hours or so. > > > > > PS: I suggested r1753426 because it is the revision that applied > > > the cxx patch to trunk. r1754535 is the revision where Kay merged > > > > Indeed. When we cut a release, we do it from a branch. So the revision > > number is relative to the AOO410 branch. > > > > > I think that identifier could still be on the patch-only version. > > > > The .patch file (in its header) carries the indication of the specific > > revision when the patch was applied to the branch. It's a bit hidden, > > but it's there. > [orcmid] > > Good enough. > > - Dennis > > > > Regards, > >Andrea. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- -- MzK "Time spent with cats is never wasted." -- Sigmund Freud
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Saturday, July 30, 2016 11:09 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > Dennis E. Hamilton wrote: > > I would like to remove those three. > > Sure, feel free to. As I wrote, they were meant as backup solutions in > case we had issues with the patch-only package. [orcmid] Done > > > I have reviewed apache-openoffice-4.1.2-patch1.zip ... > > I think this is good enough to go with. > > Perfect, then feel free to start a vote when you wish. [orcmid] Will do. Sometime in next 36 hours or so. > > > PS: I suggested r1753426 because it is the revision that applied > > the cxx patch to trunk. r1754535 is the revision where Kay merged > > Indeed. When we cut a release, we do it from a branch. So the revision > number is relative to the AOO410 branch. > > > I think that identifier could still be on the patch-only version. > > The .patch file (in its header) carries the indication of the specific > revision when the patch was applied to the branch. It's a bit hidden, > but it's there. [orcmid] Good enough. - Dennis > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Dennis E. Hamilton wrote: I would like to remove those three. Sure, feel free to. As I wrote, they were meant as backup solutions in case we had issues with the patch-only package. I have reviewed apache-openoffice-4.1.2-patch1.zip ... I think this is good enough to go with. Perfect, then feel free to start a vote when you wish. PS: I suggested r1753426 because it is the revision that applied the cxx patch to trunk. r1754535 is the revision where Kay merged Indeed. When we cut a release, we do it from a branch. So the revision number is relative to the AOO410 branch. I think that identifier could still be on the patch-only version. The .patch file (in its header) carries the indication of the specific revision when the patch was applied to the branch. It's a bit hidden, but it's there. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Saturday, July 30, 2016 05:54 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > On 30/07/2016 Dennis E. Hamilton wrote: > >> -Original Message- > >> From: Andrea Pescetti > >> So I can supply a full source package or I can give my +1 to a > "patch" > >> package that others prepare. ... > > [orcmid] I can provide the patch source package on Monday. > > Since I can only work on it today, I've uploaded to > https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/source/ > a set of files not meant for voting now. > > There is a full source release (the three files with r1754535 in their > name) and also an initial "patch-only" package named > apache-openoffice-4.1.2-patch1.zip. We will probably want to approve > just the latter; the former set is a backup solution, just in case. [orcmid] I see the following, each with their .asc, .md5, and .sha256 signatures. apache-openoffice-4.1.2-patch1.zip (28kb with expected content) Then there are the following which are not patches but apparently the entire AOO4121 source tree: apache-openoffice-4.1.2-patch1-r1754535-src.tar.bz2 (215MB) apache-openoffice-4.1.2-patch1-r1754535-src.tar.gz (284MB) apache-openoffice-4.1.2-patch1-r1754535-src.zip) (334MB) This seems like overkill, especially since I don't think we want or need those in dist/release/openoffice/4.1.2-patch1/source/ Since the 4.1.2 source archives are readily available, and applying the patch or replacing the .cxx file seems pretty easy for anyone who can use the source, I would like to remove those three. I have reviewed apache-openoffice-4.1.2-patch1.zip and the content seems just fine. I have verified the .asc signature. I have verified the md5 and sha256 hashes. SVN determines that the poly2.cxx in that .zip when extracted on Windows is indistinguishable from the same file in the fully-updated working folder from branch AOO410. I think this is good enough to go with. - Dennis PS: I suggested r1753426 because it is the revision that applied the cxx patch to trunk. r1754535 is the revision where Kay merged the fix to poly2.cxx onto AOO410. I think that identifier could still be on the patch-only version. I am not wedded to the idea [;<). > Dennis (and others): feel free to adapt and modify my initial > "patch-only" package as you see fit, feel free to replace my digital > signature with yours and start the vote when appropriate. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 30/07/2016 Dennis E. Hamilton wrote: -Original Message- From: Andrea Pescetti So I can supply a full source package or I can give my +1 to a "patch" package that others prepare. ... [orcmid] I can provide the patch source package on Monday. Since I can only work on it today, I've uploaded to https://dist.apache.org/repos/dist/dev/openoffice/4.1.2-patch1/source/ a set of files not meant for voting now. There is a full source release (the three files with r1754535 in their name) and also an initial "patch-only" package named apache-openoffice-4.1.2-patch1.zip. We will probably want to approve just the latter; the former set is a backup solution, just in case. Dennis (and others): feel free to adapt and modify my initial "patch-only" package as you see fit, feel free to replace my digital signature with yours and start the vote when appropriate. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
> -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Friday, July 29, 2016 14:23 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > On 24/07/2016 Andrea Pescetti wrote: > > To do so, an outline would be: > > 1) We commit the patch to the AOO410 branch. This is the branch used > for > > all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our > > reference version. > > This was done by Kay today (thanks!). > > > 2) We do not make any other changes to the AOO410 branch. This is > really > > meant to be a minimal update. Even the version number in the source > > package will remain 4.1.2. > > Done by Kay today (and yes, I agree that we will publish hashes of the > older libraries to make it possible to distinguish them - new libraries > come with all hashes anyway). > > > 3) We tag the release as AOO4121 and build the corresponding source > > package, which will have 4.1.2.1 in its name (I mean the filename, > > nowhere else). > > I see that Kay also created > https://svn.apache.org/viewvc/openoffice/tags/AOO4121/ which looks good. > > I've just built and tested OpenOffice from this code and I confirm it > can be released. > > So I can supply a full source package or I can give my +1 to a "patch" > package that others prepare. Since this vote is largely anticipated and > several of us built OpenOffice with the new file already, I think we can > have a 72-hour (not more) vote to comply with the standard Apache > process. Is someone is preparing the "minimal" package, please just say > so, so we can have our vote and be done with the process. [orcmid] I can provide the patch source package on Monday. - Dennis > > > 4) We don't prepare full end-user release binaries but we do supply > > repaired libraries for power users - remember the circumstances above. > > The bugfix modifies one library file, and we have binaries ready for > > several platforms already. > > We have binaries for all platform at the moment, but these are not part > of a formal vote so they can be approved separately. > > > 5) We vote on the source and possibly binaries. We advertise the > > availability of the new packages on our website, but we don't send out > > update notifications and we don't put the files on SourceForge. > > This would be next. In preparation, I've rearranged our dev area at > https://dist.apache.org/repos/dist/dev/openoffice/ [orcmid] OK, I have the new structure checked-out. - Dennis > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 24/07/2016 Andrea Pescetti wrote: To do so, an outline would be: 1) We commit the patch to the AOO410 branch. This is the branch used for all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our reference version. This was done by Kay today (thanks!). 2) We do not make any other changes to the AOO410 branch. This is really meant to be a minimal update. Even the version number in the source package will remain 4.1.2. Done by Kay today (and yes, I agree that we will publish hashes of the older libraries to make it possible to distinguish them - new libraries come with all hashes anyway). 3) We tag the release as AOO4121 and build the corresponding source package, which will have 4.1.2.1 in its name (I mean the filename, nowhere else). I see that Kay also created https://svn.apache.org/viewvc/openoffice/tags/AOO4121/ which looks good. I've just built and tested OpenOffice from this code and I confirm it can be released. So I can supply a full source package or I can give my +1 to a "patch" package that others prepare. Since this vote is largely anticipated and several of us built OpenOffice with the new file already, I think we can have a 72-hour (not more) vote to comply with the standard Apache process. Is someone is preparing the "minimal" package, please just say so, so we can have our vote and be done with the process. 4) We don't prepare full end-user release binaries but we do supply repaired libraries for power users - remember the circumstances above. The bugfix modifies one library file, and we have binaries ready for several platforms already. We have binaries for all platform at the moment, but these are not part of a formal vote so they can be approved separately. 5) We vote on the source and possibly binaries. We advertise the availability of the new packages on our website, but we don't send out update notifications and we don't put the files on SourceForge. This would be next. In preparation, I've rearranged our dev area at https://dist.apache.org/repos/dist/dev/openoffice/ Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Looks good to me. On 07/24/2016 05:37 PM, Andrea Pescetti wrote: While the severity of the security bug we disclosed http://www.openoffice.org/security/cves/CVE-2016-1513.html is not particularly high (it is classified as "Medium" with no known exploits and anti-virus software can detect malicious documents), we should release an update incorporating the -already tested- patch we disclosed in the announcement. I assume we will want to keep the effort minimal. To do so, an outline would be: 1) We commit the patch to the AOO410 branch. This is the branch used for all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our reference version. 2) We do not make any other changes to the AOO410 branch. This is really meant to be a minimal update. Even the version number in the source package will remain 4.1.2. 3) We tag the release as AOO4121 and build the corresponding source package, which will have 4.1.2.1 in its name (I mean the filename, nowhere else). 4) We don't prepare full end-user release binaries but we do supply repaired libraries for power users - remember the circumstances above. The bugfix modifies one library file, and we have binaries ready for several platforms already. 5) We vote on the source and possibly binaries. We advertise the availability of the new packages on our website, but we don't send out update notifications and we don't put the files on SourceForge. Does this look OK? Once this is done, we will probably want to open another discussion and see how we can coordinate for a release that incorporates more fixes or features and is made available in full form, with all localized installers, to end users. But the above is mostly aimed in having an official way to ship the existing patch. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 24 Jul, Dennis E. Hamilton wrote: > The patched DLL is shipped with an external digital signature. I > guess we could ask that to be installed alongside it. That would be a > good tell-tale. > > The web site where the patch is downloadable from will have hashes for > the archive containing the patched library and will also have an > external signature for that. These are on a secure AOO infrastructure > site, the best place to retrieve hashes and signature files. There is > no reason not to have a hash of the library inside the downloadable > archive for those who, for some reason, cannot check the signature but > can verify the hash. > > In the manual procedure, we will ask users to rename the existing > shared-library before copying in the replacement. This will provide a > means to revert to the patched library if a regression results. > > There is a difference in file-creation dates and in the size of the > files as well. The procedure for hotfixing with the patched library > should provide that information to discourage attempting to patch a > different release and also make it easier to tell the patch is there. > > You're right that different builds by others who look to just extract > the shared library will likely end up with a different binary of that > library. For a binary distribution from any origin that has the patch > compiled-in, I would think something like the static string might be > helpful. If we do that in the AOO4121 tag, we'll have to redo the > patched libraries we've already built. I was hoping we could avoid > that and stick with ones we have done some testing on already. > > Is what we're planning enough? I think that should be OK. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
+1 this looks like a good plan On 07/24/2016 02:37 PM, Andrea Pescetti wrote: > While the severity of the security bug we disclosed > http://www.openoffice.org/security/cves/CVE-2016-1513.html is not > particularly high (it is classified as "Medium" with no known exploits > and anti-virus software can detect malicious documents), we should > release an update incorporating the -already tested- patch we disclosed > in the announcement. > > I assume we will want to keep the effort minimal. > > To do so, an outline would be: > > 1) We commit the patch to the AOO410 branch. This is the branch used for > all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our > reference version. > > 2) We do not make any other changes to the AOO410 branch. This is really > meant to be a minimal update. Even the version number in the source > package will remain 4.1.2. > > 3) We tag the release as AOO4121 and build the corresponding source > package, which will have 4.1.2.1 in its name (I mean the filename, > nowhere else). > > 4) We don't prepare full end-user release binaries but we do supply > repaired libraries for power users - remember the circumstances above. > The bugfix modifies one library file, and we have binaries ready for > several platforms already. > > 5) We vote on the source and possibly binaries. We advertise the > availability of the new packages on our website, but we don't send out > update notifications and we don't put the files on SourceForge. > > Does this look OK? > > Once this is done, we will probably want to open another discussion and > see how we can coordinate for a release that incorporates more fixes or > features and is made available in full form, with all localized > installers, to end users. But the above is mostly aimed in having an > official way to ship the existing patch. > > Regards, > Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@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-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Am 07/25/2016 12:45 AM, schrieb Dennis E. Hamilton: The patched DLL is shipped with an external digital signature. I guess we could ask that to be installed alongside it. That would be a good tell-tale. The web site where the patch is downloadable from will have hashes for the archive containing the patched library and will also have an external signature for that. These are on a secure AOO infrastructure site, the best place to retrieve hashes and signature files. There is no reason not to have a hash of the library inside the downloadable archive for those who, for some reason, cannot check the signature but can verify the hash. In the manual procedure, we will ask users to rename the existing shared-library before copying in the replacement. This will provide a means to revert to the patched library if a regression results. There is a difference in file-creation dates and in the size of the files as well. The procedure for hotfixing with the patched library should provide that information to discourage attempting to patch a different release and also make it easier to tell the patch is there. You're right that different builds by others who look to just extract the shared library will likely end up with a different binary of that library. For a binary distribution from any origin that has the patch compiled-in, I would think something like the static string might be helpful. If we do that in the AOO4121 tag, we'll have to redo the patched libraries we've already built. I was hoping we could avoid that and stick with ones we have done some testing on already. - file size - file date+time - hash value - signature. With this we have IMHO enough differences to give the users at hand so that they can see whats old and new. Then we have enough differences to avoid to touch the source again. However, I appreciate this easy and clever thing to make the difference visible. Is what we're planning enough? For the moment I think so. Marcus -Original Message- From: Don Lewis [mailto:truck...@apache.org] Sent: Sunday, July 24, 2016 15:14 To: dev@openoffice.apache.org Subject: Re: Officially releasing a patch for CVE-2016-1513 On 24 Jul, Don Lewis wrote: At a minimum, we should publish the hash values of buggy and fixed versions of the library. That might not help someone who builds and installs from source since the build not be completely repeatable. For instance the library might contain a timestamp. Adding a static string "CVE-2016-1513 Fixed" to the source is another possibiliy. On *nix, the user/administrator can run: strings whatever.so | grep CVE and look for the above to verify that the fixed library has been installed. Someone would have to figure out how to do the equivalent on Windows. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
Thanks for the list. Apart from the differences thing it looks good to me. Marcus Am 07/24/2016 11:37 PM, schrieb Andrea Pescetti: While the severity of the security bug we disclosed http://www.openoffice.org/security/cves/CVE-2016-1513.html is not particularly high (it is classified as "Medium" with no known exploits and anti-virus software can detect malicious documents), we should release an update incorporating the -already tested- patch we disclosed in the announcement. I assume we will want to keep the effort minimal. To do so, an outline would be: 1) We commit the patch to the AOO410 branch. This is the branch used for all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our reference version. 2) We do not make any other changes to the AOO410 branch. This is really meant to be a minimal update. Even the version number in the source package will remain 4.1.2. 3) We tag the release as AOO4121 and build the corresponding source package, which will have 4.1.2.1 in its name (I mean the filename, nowhere else). 4) We don't prepare full end-user release binaries but we do supply repaired libraries for power users - remember the circumstances above. The bugfix modifies one library file, and we have binaries ready for several platforms already. 5) We vote on the source and possibly binaries. We advertise the availability of the new packages on our website, but we don't send out update notifications and we don't put the files on SourceForge. Does this look OK? Once this is done, we will probably want to open another discussion and see how we can coordinate for a release that incorporates more fixes or features and is made available in full form, with all localized installers, to end users. But the above is mostly aimed in having an official way to ship the existing patch. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
The patched DLL is shipped with an external digital signature. I guess we could ask that to be installed alongside it. That would be a good tell-tale. The web site where the patch is downloadable from will have hashes for the archive containing the patched library and will also have an external signature for that. These are on a secure AOO infrastructure site, the best place to retrieve hashes and signature files. There is no reason not to have a hash of the library inside the downloadable archive for those who, for some reason, cannot check the signature but can verify the hash. In the manual procedure, we will ask users to rename the existing shared-library before copying in the replacement. This will provide a means to revert to the patched library if a regression results. There is a difference in file-creation dates and in the size of the files as well. The procedure for hotfixing with the patched library should provide that information to discourage attempting to patch a different release and also make it easier to tell the patch is there. You're right that different builds by others who look to just extract the shared library will likely end up with a different binary of that library. For a binary distribution from any origin that has the patch compiled-in, I would think something like the static string might be helpful. If we do that in the AOO4121 tag, we'll have to redo the patched libraries we've already built. I was hoping we could avoid that and stick with ones we have done some testing on already. Is what we're planning enough? - Dennis > -Original Message- > From: Don Lewis [mailto:truck...@apache.org] > Sent: Sunday, July 24, 2016 15:14 > To: dev@openoffice.apache.org > Subject: Re: Officially releasing a patch for CVE-2016-1513 > > On 24 Jul, Don Lewis wrote: > > > At a minimum, we should publish the hash values of buggy and fixed > > versions of the library. That might not help someone who builds and > > installs from source since the build not be completely repeatable. > > For instance the library might contain a timestamp. > > Adding a static string "CVE-2016-1513 Fixed" to the source is another > possibiliy. On *nix, the user/administrator can run: > strings whatever.so | grep CVE > and look for the above to verify that the fixed library has been > installed. Someone would have to figure out how to do the equivalent on > Windows. > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 24 Jul, Don Lewis wrote: > At a minimum, we should publish the hash values of buggy and fixed > versions of the library. That might not help someone who builds and > installs from source since the build not be completely repeatable. > For instance the library might contain a timestamp. Adding a static string "CVE-2016-1513 Fixed" to the source is another possibiliy. On *nix, the user/administrator can run: strings whatever.so | grep CVE and look for the above to verify that the fixed library has been installed. Someone would have to figure out how to do the equivalent on Windows. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Officially releasing a patch for CVE-2016-1513
On 24 Jul, Andrea Pescetti wrote: > While the severity of the security bug we disclosed > http://www.openoffice.org/security/cves/CVE-2016-1513.html is not > particularly high (it is classified as "Medium" with no known exploits > and anti-virus software can detect malicious documents), we should > release an update incorporating the -already tested- patch we disclosed > in the announcement. > > I assume we will want to keep the effort minimal. > > To do so, an outline would be: > > 1) We commit the patch to the AOO410 branch. This is the branch used for > all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our > reference version. > > 2) We do not make any other changes to the AOO410 branch. This is really > meant to be a minimal update. Even the version number in the source > package will remain 4.1.2. > > 3) We tag the release as AOO4121 and build the corresponding source > package, which will have 4.1.2.1 in its name (I mean the filename, > nowhere else). > > 4) We don't prepare full end-user release binaries but we do supply > repaired libraries for power users - remember the circumstances above. > The bugfix modifies one library file, and we have binaries ready for > several platforms already. > > 5) We vote on the source and possibly binaries. We advertise the > availability of the new packages on our website, but we don't send out > update notifications and we don't put the files on SourceForge. > > Does this look OK? Not being able to tell at a glance whether a copy of AOO has been fixed or not is bad. A while back Samsung fixed a hard drive firmware bug that could cause data loss, but didn't change the firmware version number. It was impossible to discern whether a drive had the buggy or fixed firmware with smartctl or by looking at boot messages. I ended up putting stickers on drives after I updated the firmware, but there was still no way to survey all the drives to see if they were fixed once they were installed in boxes. At a minimum, we should publish the hash values of buggy and fixed versions of the library. That might not help someone who builds and installs from source since the build not be completely repeatable. For instance the library might contain a timestamp. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Officially releasing a patch for CVE-2016-1513
[BCC to PMC, AOO Security team where how to accomplish this has been under discussion] +1 from me, all the way down the line. > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Sunday, July 24, 2016 14:38 > To: dev@openoffice.apache.org > Subject: Officially releasing a patch for CVE-2016-1513 > > While the severity of the security bug we disclosed > http://www.openoffice.org/security/cves/CVE-2016-1513.html is not > particularly high (it is classified as "Medium" with no known exploits > and anti-virus software can detect malicious documents), we should > release an update incorporating the -already tested- patch we disclosed > in the announcement. > > I assume we will want to keep the effort minimal. > > To do so, an outline would be: > > 1) We commit the patch to the AOO410 branch. This is the branch used for > all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our > reference version. > > 2) We do not make any other changes to the AOO410 branch. This is really > meant to be a minimal update. Even the version number in the source > package will remain 4.1.2. > > 3) We tag the release as AOO4121 and build the corresponding source > package, which will have 4.1.2.1 in its name (I mean the filename, > nowhere else). > > 4) We don't prepare full end-user release binaries but we do supply > repaired libraries for power users - remember the circumstances above. > The bugfix modifies one library file, and we have binaries ready for > several platforms already. > > 5) We vote on the source and possibly binaries. We advertise the > availability of the new packages on our website, but we don't send out > update notifications and we don't put the files on SourceForge. > > Does this look OK? > > Once this is done, we will probably want to open another discussion and > see how we can coordinate for a release that incorporates more fixes or > features and is made available in full form, with all localized > installers, to end users. But the above is mostly aimed in having an > official way to ship the existing patch. > > Regards, >Andrea. > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Officially releasing a patch for CVE-2016-1513
While the severity of the security bug we disclosed http://www.openoffice.org/security/cves/CVE-2016-1513.html is not particularly high (it is classified as "Medium" with no known exploits and anti-virus software can detect malicious documents), we should release an update incorporating the -already tested- patch we disclosed in the announcement. I assume we will want to keep the effort minimal. To do so, an outline would be: 1) We commit the patch to the AOO410 branch. This is the branch used for all the 4.1.x series. 4.2.0 isn't out yet, so 4.1.x is still our reference version. 2) We do not make any other changes to the AOO410 branch. This is really meant to be a minimal update. Even the version number in the source package will remain 4.1.2. 3) We tag the release as AOO4121 and build the corresponding source package, which will have 4.1.2.1 in its name (I mean the filename, nowhere else). 4) We don't prepare full end-user release binaries but we do supply repaired libraries for power users - remember the circumstances above. The bugfix modifies one library file, and we have binaries ready for several platforms already. 5) We vote on the source and possibly binaries. We advertise the availability of the new packages on our website, but we don't send out update notifications and we don't put the files on SourceForge. Does this look OK? Once this is done, we will probably want to open another discussion and see how we can coordinate for a release that incorporates more fixes or features and is made available in full form, with all localized installers, to end users. But the above is mostly aimed in having an official way to ship the existing patch. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
