Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On 13/12/2014 jan i wrote:
8.1 and above, it complains when you start the exe after installation.
To people who were waiting for developments in this discussion: a new
one ("Digital signing release for windows") has been started, so please
follow it and I'll post my replies there too. See also the "OpenOffice
and Infrastructure: ApacheCon meeting" discussion. Contrary to popular
belief, nothing useful to our purpose was discussed on private lists.
Regards,
Andrea.
-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On Saturday, December 13, 2014, Dennis E. Hamilton wrote: > It appears that running SignTool on an .exe is deceptively simple. > > I have some other tasks to complete before I can install a Microsoft SDK > that has the tool. I will try SignTool over the weekend. That was actually what I did when testing the signing process, but bear in mind you need a valid certificate. I hope you will see the same as I did (and rob made a bet on) windows 8.0 and below accept that the installer is signed and everything is ok, with 8.1 and above, it complains when you start the exe after installation. rgds jan i > > - Dennis > > -Original Message- > From: Rob Weir [mailto:r...@robweir.com ] > Sent: Tuesday, December 9, 2014 15:56 > To: dev@openoffice.apache.org ; Dennis Hamilton > Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter) > > On Tue, Dec 9, 2014 at 5:19 PM, Dennis E. Hamilton > > wrote: > [ ... ] > > I don't understand why full rebuilds are required. The only crucial > file that needs signing is the .exe that is downloaded and extracts the > actual setup files. All it does is extract a number of fixed files and > then run the extracted setup.exe. > > > > [ ... ] > > Of course, nothing requires that we go for certification. I bet if > we just signed the outermost installer it would be satisfy earlier > versions of Windows, antivirus apps and browsers that are doing this > kind of check.So it might be worth doing just this minimum > initially. > > Regards, > > -Rob > > > > If a signed version of that .exe can be created, using the existing > setups delivered with the current 4.1.1 .exe files, there is nothing else > to do. It has to be done once for each language, but that's it. No full > rebuilds, no new dates on files. The extracted setups would be binary > identical to each of the current ones for 4.1.1, so it is easy to verify > that the signed .exe does not deliver anything but the already reviewed > installs. > > > > That might be unworkable, but it is definitely worth seeing if it is > possible rather than going through a full-up set of build processes. > > > [ ... ] > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > -- Sent from My iPad, sorry for any misspellings.
RE: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
It appears that running SignTool on an .exe is deceptively simple. I have some other tasks to complete before I can install a Microsoft SDK that has the tool. I will try SignTool over the weekend. - Dennis -Original Message- From: Rob Weir [mailto:r...@robweir.com] Sent: Tuesday, December 9, 2014 15:56 To: dev@openoffice.apache.org; Dennis Hamilton Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter) On Tue, Dec 9, 2014 at 5:19 PM, Dennis E. Hamilton wrote: [ ... ] > I don't understand why full rebuilds are required. The only crucial file > that needs signing is the .exe that is downloaded and extracts the actual > setup files. All it does is extract a number of fixed files and then run the > extracted setup.exe. > [ ... ] Of course, nothing requires that we go for certification. I bet if we just signed the outermost installer it would be satisfy earlier versions of Windows, antivirus apps and browsers that are doing this kind of check.So it might be worth doing just this minimum initially. Regards, -Rob > If a signed version of that .exe can be created, using the existing setups > delivered with the current 4.1.1 .exe files, there is nothing else to do. It > has to be done once for each language, but that's it. No full rebuilds, no > new dates on files. The extracted setups would be binary identical to each > of the current ones for 4.1.1, so it is easy to verify that the signed .exe > does not deliver anything but the already reviewed installs. > > That might be unworkable, but it is definitely worth seeing if it is possible > rather than going through a full-up set of build processes. > [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On Tue, Dec 9, 2014 at 5:19 PM, Dennis E. Hamilton wrote: > +1 (non-binding [;<) on PMC approval of any slip-stream. > > I don't understand why full rebuilds are required. The only crucial file > that needs signing is the .exe that is downloaded and extracts the actual > setup files. All it does is extract a number of fixed files and then run the > extracted setup.exe. > We found this out when we took AOO through the Windows 8 certification testing tool.They have something new called "kernel-mode code signing" where they check each exe, dll, sys , etc., for a digital signature at load time. So certification requires we sign any executable code and then do it for the outermost installer as well. Of course, nothing requires that we go for certification. I bet if we just signed the outermost installer it would be satisfy earlier versions of Windows, antivirus apps and browsers that are doing this kind of check.So it might be worth doing just this minimum initially. Regards, -Rob > If a signed version of that .exe can be created, using the existing setups > delivered with the current 4.1.1 .exe files, there is nothing else to do. It > has to be done once for each language, but that's it. No full rebuilds, no > new dates on files. The extracted setups would be binary identical to each > of the current ones for 4.1.1, so it is easy to verify that the signed .exe > does not deliver anything but the already reviewed installs. > > That might be unworkable, but it is definitely worth seeing if it is possible > rather than going through a full-up set of build processes. > > - Dennis > > PS: Rob's analysis is very useful to keep in mind as we look at other ways to > increase confidence in the AOO binaries and the AOO site as preferable for > those downloads. I think grabbing the low-hanging fruit and getting > something simple through the process is also desirable, especially since we > are starting from zero using the signing process. > > > -Original Message- > From: jan i [mailto:j...@apache.org] > Sent: Tuesday, December 9, 2014 08:29 > To: dev; Dennis Hamilton > Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter) > > On 9 December 2014 at 16:26, Dennis E. Hamilton > wrote: > >> Andrea, >> > [ ... ] >> (Or even sign the existing installer >> file, if it is in the proper format for inserting the information and >> signature.) That is, the .cab, .msi, and setup.exe would be completely >> unchanged. >> > No we need to rebuild (and for every language), because the last step in > the build process needs to be repeated, we cannot just patch the files. > > If we could move away from 1 install set pr language, the job would be > about 30 times faster :-) > > > > > AOO is special compared to most other projects, in that the majority of our > users use the binary package. As a consequence, I recommend a PMC vote, > even if its not strictly needed. > > [ ... ] > >> >> It would still have to be project-managed in the sense that all of the >> measures to preserve binary authenticity and provide accompanying binary >> release management internal to AOO should be followed. >> > [ ... ] > > > - > 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: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
+1 (non-binding [;<) on PMC approval of any slip-stream. I don't understand why full rebuilds are required. The only crucial file that needs signing is the .exe that is downloaded and extracts the actual setup files. All it does is extract a number of fixed files and then run the extracted setup.exe. If a signed version of that .exe can be created, using the existing setups delivered with the current 4.1.1 .exe files, there is nothing else to do. It has to be done once for each language, but that's it. No full rebuilds, no new dates on files. The extracted setups would be binary identical to each of the current ones for 4.1.1, so it is easy to verify that the signed .exe does not deliver anything but the already reviewed installs. That might be unworkable, but it is definitely worth seeing if it is possible rather than going through a full-up set of build processes. - Dennis PS: Rob's analysis is very useful to keep in mind as we look at other ways to increase confidence in the AOO binaries and the AOO site as preferable for those downloads. I think grabbing the low-hanging fruit and getting something simple through the process is also desirable, especially since we are starting from zero using the signing process. -Original Message- From: jan i [mailto:j...@apache.org] Sent: Tuesday, December 9, 2014 08:29 To: dev; Dennis Hamilton Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter) On 9 December 2014 at 16:26, Dennis E. Hamilton wrote: > Andrea, > [ ... ] > (Or even sign the existing installer > file, if it is in the proper format for inserting the information and > signature.) That is, the .cab, .msi, and setup.exe would be completely > unchanged. > No we need to rebuild (and for every language), because the last step in the build process needs to be repeated, we cannot just patch the files. If we could move away from 1 install set pr language, the job would be about 30 times faster :-) AOO is special compared to most other projects, in that the majority of our users use the binary package. As a consequence, I recommend a PMC vote, even if its not strictly needed. [ ... ] > > It would still have to be project-managed in the sense that all of the > measures to preserve binary authenticity and provide accompanying binary > release management internal to AOO should be followed. > [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On Tue, Dec 9, 2014 at 3:21 PM, jan i wrote: > On Tuesday, December 9, 2014, Rob Weir wrote: > >> On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton >> > wrote: >> > I don't know if this is helpful or not. I'm not in a position to check. >> > >> > Thinking out loud: >> > >> > There are two cases of signatures. >> > >> > 1. Digital signing of installable components, such as DLLs and such. >> This is also important but a second-order problem. >> > >> > 2. Digital signing of the installer binary (the .EXE). That or >> shipping a signed .MSI. >> > This is more important. It has to do with raising the confidence in >> downloads and installs and is of immediate benefit. >> > >> > It *may* be the case that the installer binary .EXE already has room in >> the file for a signature and it is simply not being used. The properties >> on the binary .EXE are also not filled in for AOO 4.1.1 en-US. Those are >> the ones that show a File description, File version, Product name, Product >> version, Copyright, Language, etc. >> > >> > It might be worthwhile to see if the properties and signature can be >> injected in the .EXE already. And if not, it may be possible to rebuild >> the .EXE, since the bits are still around. They are what are extracted >> into a folder which is then used for running setup. >> > >> > If feasible, this strikes me as a perfectly worthwhile exercise for >> slip-streaming a signed binary of AOO 4.1.1 for Windows. As Andrea >> remarks, It would also be a right-sized teething exercise for our learning >> how to work through the signing process. >> > >> >> I'm rather pessimistic. >> >> Here's what I see as the main user annoyances related the integrity of >> AOO downloads: >> >> 1) Scams that ask for payment and then redirect to genuine versions of >> AOO. So the user has lost before they even download a single byte of >> our package. Signing will not help them, >> >> 2) Scams that wrap AOO's installer with an "installer" or similar app >> that takes the user through a complicated set of screens to accept >> various "offers" that result in adware/malware/badware being >> installed. Only then does it chain to the genuine AOO install. >> Again, signing doesn't help the user. > > > as long as we don't have a signed installer nobody can tell the > difference, but with a signed installer we would have a harder argument > (agreed if people listen) ? > Not really. In the above cases the damage is done*before* the user ever launches our installer. So in these cases whether it is signed or not doesn't matter. >> >> 3) Download pages that offer genuine AOO downloads, but the page is >> filled with other advertisements that lure the user into clicking >> them, some which even claim they are the AOO download. Signing >> doesn't help the user much here. >> >> Note that in all of these cases, the bad code, the installer/wrapper >> code could have a digital signature as well. So user education -- >> don't run unsigned code -- doesn't really solve the problem here as >> well. >> >> 4) Annoyance of users who download genuine AOO from our website and >> need to deal with extra mouse clicks to dismiss warning dialogs from >> the browser, OS, antivirus, etc. This is the main thing signing >> fixes. >> >> This is worth doing, I think, for benefit #4. But by itself it >> doesn't really drain the swamp. Note in particular that I have not >> seen someone actually modify the AOO code or installer to make >> malware. Signing would help with that, if it happened. But today >> there are far easier scams. > > > I agree with what you write, but I think you bypass a important point. > Everybody tells now more than ever that we are dead...which is by far > not true, and making a real volunteer release would show that clearly. (I > appreciate what the paid developer do, so please don't be offended). > > To me digital signing is a nice way to show our community and users that > AOO is still a major factor in this part of the world. > I'm not arguing against a release or against signing. I'm just pointing out that the scammers are two steps ahead of us, and even with signing most of the problems still remain. Regards, -Rob > > > >> Regards, >> >> -Rob >> >> >> >> >> >> >> > I'm all for starting with the least that could possibly work, even >> though I have no expertise on this. >> > >> > - Dennis >> > >> > -Original Message- >> > From: Andrea Pescetti [mailto:pesce...@apache.org ] >> > Sent: Monday, December 8, 2014 15:08 >> > To: dev@openoffice.apache.org >> > Subject: Re: Budapest and thereafter. >> > >> > Marcus wrote: >> >> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti: >> >>> We could actually do both, if you believe it makes sense: >> >>> - signed 4.1.1 (next Windows binaries only) by end of December >> >>> - 4.1.2 in January >> >> IMHO this doesn't make sense and would be just a waste of resources, >> >> when doing 2 releases in such a short time frame. >> >> But I would t
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On Tuesday, December 9, 2014, Rob Weir wrote: > On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton > > wrote: > > I don't know if this is helpful or not. I'm not in a position to check. > > > > Thinking out loud: > > > > There are two cases of signatures. > > > > 1. Digital signing of installable components, such as DLLs and such. > This is also important but a second-order problem. > > > > 2. Digital signing of the installer binary (the .EXE). That or > shipping a signed .MSI. > > This is more important. It has to do with raising the confidence in > downloads and installs and is of immediate benefit. > > > > It *may* be the case that the installer binary .EXE already has room in > the file for a signature and it is simply not being used. The properties > on the binary .EXE are also not filled in for AOO 4.1.1 en-US. Those are > the ones that show a File description, File version, Product name, Product > version, Copyright, Language, etc. > > > > It might be worthwhile to see if the properties and signature can be > injected in the .EXE already. And if not, it may be possible to rebuild > the .EXE, since the bits are still around. They are what are extracted > into a folder which is then used for running setup. > > > > If feasible, this strikes me as a perfectly worthwhile exercise for > slip-streaming a signed binary of AOO 4.1.1 for Windows. As Andrea > remarks, It would also be a right-sized teething exercise for our learning > how to work through the signing process. > > > > I'm rather pessimistic. > > Here's what I see as the main user annoyances related the integrity of > AOO downloads: > > 1) Scams that ask for payment and then redirect to genuine versions of > AOO. So the user has lost before they even download a single byte of > our package. Signing will not help them, > > 2) Scams that wrap AOO's installer with an "installer" or similar app > that takes the user through a complicated set of screens to accept > various "offers" that result in adware/malware/badware being > installed. Only then does it chain to the genuine AOO install. > Again, signing doesn't help the user. as long as we don't have a signed installer nobody can tell the difference, but with a signed installer we would have a harder argument (agreed if people listen) ? > > 3) Download pages that offer genuine AOO downloads, but the page is > filled with other advertisements that lure the user into clicking > them, some which even claim they are the AOO download. Signing > doesn't help the user much here. > > Note that in all of these cases, the bad code, the installer/wrapper > code could have a digital signature as well. So user education -- > don't run unsigned code -- doesn't really solve the problem here as > well. > > 4) Annoyance of users who download genuine AOO from our website and > need to deal with extra mouse clicks to dismiss warning dialogs from > the browser, OS, antivirus, etc. This is the main thing signing > fixes. > > This is worth doing, I think, for benefit #4. But by itself it > doesn't really drain the swamp. Note in particular that I have not > seen someone actually modify the AOO code or installer to make > malware. Signing would help with that, if it happened. But today > there are far easier scams. I agree with what you write, but I think you bypass a important point. Everybody tells now more than ever that we are dead...which is by far not true, and making a real volunteer release would show that clearly. (I appreciate what the paid developer do, so please don't be offended). To me digital signing is a nice way to show our community and users that AOO is still a major factor in this part of the world. > Regards, > > -Rob > > > > > > > > I'm all for starting with the least that could possibly work, even > though I have no expertise on this. > > > > - Dennis > > > > -Original Message- > > From: Andrea Pescetti [mailto:pesce...@apache.org ] > > Sent: Monday, December 8, 2014 15:08 > > To: dev@openoffice.apache.org > > Subject: Re: Budapest and thereafter. > > > > Marcus wrote: > >> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti: > >>> We could actually do both, if you believe it makes sense: > >>> - signed 4.1.1 (next Windows binaries only) by end of December > >>> - 4.1.2 in January > >> IMHO this doesn't make sense and would be just a waste of resources, > >> when doing 2 releases in such a short time frame. > >> But I would tend to do only the bigger release (4.1.2) - let's say in > >> January/February. When ... > > > > Honestly, Infra would like (and they are right) that after asking for > > years for digital signing, we actually use it. We can't put many > > obstacles in front of it. So a long list of things that we must have > > ready before that won't work. Signing Windows binaries will have to > > happen, and users will benefit from it in terms of trust in OpenOffice. > > > > Assuming that more or less we can master the technology, distributing
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton wrote: > I don't know if this is helpful or not. I'm not in a position to check. > > Thinking out loud: > > There are two cases of signatures. > > 1. Digital signing of installable components, such as DLLs and such. This > is also important but a second-order problem. > > 2. Digital signing of the installer binary (the .EXE). That or shipping a > signed .MSI. > This is more important. It has to do with raising the confidence in > downloads and installs and is of immediate benefit. > > It *may* be the case that the installer binary .EXE already has room in the > file for a signature and it is simply not being used. The properties on the > binary .EXE are also not filled in for AOO 4.1.1 en-US. Those are the ones > that show a File description, File version, Product name, Product version, > Copyright, Language, etc. > > It might be worthwhile to see if the properties and signature can be injected > in the .EXE already. And if not, it may be possible to rebuild the .EXE, > since the bits are still around. They are what are extracted into a folder > which is then used for running setup. > > If feasible, this strikes me as a perfectly worthwhile exercise for > slip-streaming a signed binary of AOO 4.1.1 for Windows. As Andrea remarks, > It would also be a right-sized teething exercise for our learning how to work > through the signing process. > I'm rather pessimistic. Here's what I see as the main user annoyances related the integrity of AOO downloads: 1) Scams that ask for payment and then redirect to genuine versions of AOO. So the user has lost before they even download a single byte of our package. Signing will not help them, 2) Scams that wrap AOO's installer with an "installer" or similar app that takes the user through a complicated set of screens to accept various "offers" that result in adware/malware/badware being installed. Only then does it chain to the genuine AOO install. Again, signing doesn't help the user. 3) Download pages that offer genuine AOO downloads, but the page is filled with other advertisements that lure the user into clicking them, some which even claim they are the AOO download. Signing doesn't help the user much here. Note that in all of these cases, the bad code, the installer/wrapper code could have a digital signature as well. So user education -- don't run unsigned code -- doesn't really solve the problem here as well. 4) Annoyance of users who download genuine AOO from our website and need to deal with extra mouse clicks to dismiss warning dialogs from the browser, OS, antivirus, etc. This is the main thing signing fixes. This is worth doing, I think, for benefit #4. But by itself it doesn't really drain the swamp. Note in particular that I have not seen someone actually modify the AOO code or installer to make malware. Signing would help with that, if it happened. But today there are far easier scams. Regards, -Rob > I'm all for starting with the least that could possibly work, even though I > have no expertise on this. > > - Dennis > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Monday, December 8, 2014 15:08 > To: dev@openoffice.apache.org > Subject: Re: Budapest and thereafter. > > Marcus wrote: >> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti: >>> We could actually do both, if you believe it makes sense: >>> - signed 4.1.1 (next Windows binaries only) by end of December >>> - 4.1.2 in January >> IMHO this doesn't make sense and would be just a waste of resources, >> when doing 2 releases in such a short time frame. >> But I would tend to do only the bigger release (4.1.2) - let's say in >> January/February. When ... > > Honestly, Infra would like (and they are right) that after asking for > years for digital signing, we actually use it. We can't put many > obstacles in front of it. So a long list of things that we must have > ready before that won't work. Signing Windows binaries will have to > happen, and users will benefit from it in terms of trust in OpenOffice. > > Assuming that more or less we can master the technology, distributing > the 4.1.1 signed binaries is not a huge feat for us (it would need > production of the new binaries and their upload to a new directory like > "windows-signed" and defaulting to "windows-signed" in the JavaScript in > the download page). It is far less than a release and at least it could > show that on this (new for OpenOffice) topic we are ready. > > In case I wasn't clear (and this is my fault for not summarizing the > Budapest talks correctly) signed binaries have high priority. One way is > to make a 4.1.2 release and sign it, and this requires going through the > whole process (no, it can't be a Windows-only release). Another way is > to ship a signed version of the existing 4.1.1 binaries as a "warm up" > for the moment when this will be integral part of the release pro
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On 9 December 2014 at 16:26, Dennis E. Hamilton wrote: > Andrea, > > Although I consider this very important, I am so far back the learning > curve on working with the actual bits that I don't think I can provide > anything competent in a short time. If you think there is an useful way > for me to move along the curve in time to be useful, I am open to it. > > One question, also for Jürgen and Jan. Is it possible to enter the > signing process for just the last step -- using the 4.1.1 setup files, > which are easily available, and making an installer file with appropriate > file properties and a signature? (Or even sign the existing installer > file, if it is in the proper format for inserting the information and > signature.) That is, the .cab, .msi, and setup.exe would be completely > unchanged. > No we need to rebuild (and for every language), because the last step in the build process needs to be repeated, we cannot just patch the files. If we could move away from 1 install set pr language, the job would be about 30 times faster :-) > > It is not the whole job, but it would make for an easy 4.1.1 slip-stream > update and start solving one of the problems of being able to identify the > origin of "courtesy" binaries that the project is willing to support. > > (There are loud reminders on other lists that courtesy binaries are not > Apache capital-R Releases, only the sources are, so this would technically > not involve a new AOO Project Release at all. There should be absolutely > no difference other than the installer is authenticated and makes Windows > happier in itself, without worrying about Windows certification at this > stage.) > AOO is special compared to most other projects, in that the majority of our users use the binary package. As a consequence, I recommend a PMC vote, even if its not strictly needed. rgds jan i. > > It would still have to be project-managed in the sense that all of the > measures to preserve binary authenticity and provide accompanying binary > release management internal to AOO should be followed. > > Still thinking out loud, wanting to be helpful. > > - Dennis > > PS: Corinthia has to learn to do this anyhow, but that incubator has the > advantage of not being under any time pressure and can provide signed > binaries from the beginning, so teething and preserving the knowledge may > be easier. > > > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Tuesday, December 9, 2014 00:17 > To: dev@openoffice.apache.org > Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter) > > Jürgen Schmidt wrote: > > We had a signing mechanism in place for a long time and the reason why > > we have currently no digital signing is the lack of a certificate where > > we as project (PMC) or as representative the release manager have enough > > control. > > I do have a certificate and access key to the signing service. Details > in my "OpenOffice and Infra" report > http://markmail.org/message/6ymi35tajswcfsps item 4. > > Of course, I'm more than happy if someone else is willing to help with > this; maybe Jan's work of months ago can now be reused and we can sign > with minimal effort. > > 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: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
Andrea, Although I consider this very important, I am so far back the learning curve on working with the actual bits that I don't think I can provide anything competent in a short time. If you think there is an useful way for me to move along the curve in time to be useful, I am open to it. One question, also for Jürgen and Jan. Is it possible to enter the signing process for just the last step -- using the 4.1.1 setup files, which are easily available, and making an installer file with appropriate file properties and a signature? (Or even sign the existing installer file, if it is in the proper format for inserting the information and signature.) That is, the .cab, .msi, and setup.exe would be completely unchanged. It is not the whole job, but it would make for an easy 4.1.1 slip-stream update and start solving one of the problems of being able to identify the origin of "courtesy" binaries that the project is willing to support. (There are loud reminders on other lists that courtesy binaries are not Apache capital-R Releases, only the sources are, so this would technically not involve a new AOO Project Release at all. There should be absolutely no difference other than the installer is authenticated and makes Windows happier in itself, without worrying about Windows certification at this stage.) It would still have to be project-managed in the sense that all of the measures to preserve binary authenticity and provide accompanying binary release management internal to AOO should be followed. Still thinking out loud, wanting to be helpful. - Dennis PS: Corinthia has to learn to do this anyhow, but that incubator has the advantage of not being under any time pressure and can provide signed binaries from the beginning, so teething and preserving the knowledge may be easier. -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Tuesday, December 9, 2014 00:17 To: dev@openoffice.apache.org Subject: Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter) Jürgen Schmidt wrote: > We had a signing mechanism in place for a long time and the reason why > we have currently no digital signing is the lack of a certificate where > we as project (PMC) or as representative the release manager have enough > control. I do have a certificate and access key to the signing service. Details in my "OpenOffice and Infra" report http://markmail.org/message/6ymi35tajswcfsps item 4. Of course, I'm more than happy if someone else is willing to help with this; maybe Jan's work of months ago can now be reused and we can sign with minimal effort. 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: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On Tuesday, December 9, 2014, Jürgen Schmidt wrote: > On 09/12/14 09:17, Andrea Pescetti wrote: > > Jürgen Schmidt wrote: > >> We had a signing mechanism in place for a long time and the reason why > >> we have currently no digital signing is the lack of a certificate where > >> we as project (PMC) or as representative the release manager have enough > >> control. > > > > I do have a certificate and access key to the signing service. Details > > in my "OpenOffice and Infra" report > > http://markmail.org/message/6ymi35tajswcfsps item 4. > > > > Of course, I'm more than happy if someone else is willing to help with > > this; maybe Jan's work of months ago can now be reused and we can sign > > with minimal effort. > > I don't have time to do it but I would start with analyzing which parts > have to be signed. The former process signed all binary artifacts (dll, > jars, .NET assemblies, ...). I am not sure if this is all necessary or > if it was just signed for simplification. > > The new mechanism requires a more or less rework of the signing process. > And it will result probably in a multiphase signing and packaging > process. First round is to sign exe, dlls, assemblies etc. figured out > in the initial analysis. Second step is to package the msi and the > setup.exe. And finally package the downloadable exe and sign this as well. > > Of course anybody can do the investigation again, but the rule is quite clear. Windows loadable components must be signed, in our case jar, dll and exe. I did not change a bit in the build system for my test, but had simple one-liner scrips to help. First script runs through all release languages, run configure and make. then renames the output dir with dll etc. (it also renamed the dll,jar to xyz.lang.dll) Second step was manual, upload to symantic gui and sign, download the signed artifacts Second script runs through all release languages, renames the output dir back, runs configure and then make postprocess. Finally it renames the install set. Last step was manual, upload all instlallers to symantic, sign and download. we (infra) spent quite sometime discussing a local solution, but it turned out to be vey costly (both in terms of real money and man hours). We then say that symantic actually provide at least 80% of the solution we looked at, so the choice was simple. rgds jan i > Juergen > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > -- Sent from My iPad, sorry for any misspellings.
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On 09/12/14 09:17, Andrea Pescetti wrote: > Jürgen Schmidt wrote: >> We had a signing mechanism in place for a long time and the reason why >> we have currently no digital signing is the lack of a certificate where >> we as project (PMC) or as representative the release manager have enough >> control. > > I do have a certificate and access key to the signing service. Details > in my "OpenOffice and Infra" report > http://markmail.org/message/6ymi35tajswcfsps item 4. > > Of course, I'm more than happy if someone else is willing to help with > this; maybe Jan's work of months ago can now be reused and we can sign > with minimal effort. I don't have time to do it but I would start with analyzing which parts have to be signed. The former process signed all binary artifacts (dll, jars, .NET assemblies, ...). I am not sure if this is all necessary or if it was just signed for simplification. The new mechanism requires a more or less rework of the signing process. And it will result probably in a multiphase signing and packaging process. First round is to sign exe, dlls, assemblies etc. figured out in the initial analysis. Second step is to package the msi and the setup.exe. And finally package the downloadable exe and sign this as well. Juergen - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
Jürgen Schmidt wrote: We had a signing mechanism in place for a long time and the reason why we have currently no digital signing is the lack of a certificate where we as project (PMC) or as representative the release manager have enough control. I do have a certificate and access key to the signing service. Details in my "OpenOffice and Infra" report http://markmail.org/message/6ymi35tajswcfsps item 4. Of course, I'm more than happy if someone else is willing to help with this; maybe Jan's work of months ago can now be reused and we can sign with minimal effort. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Signing AOO 4.1.1 (was RE: Budapest and thereafter)
On 09/12/14 03:29, Dennis E. Hamilton wrote: > I don't know if this is helpful or not. I'm not in a position to check. > > Thinking out loud: > > There are two cases of signatures. > > 1. Digital signing of installable components, such as DLLs and such. This > is also important but a second-order problem. > > 2. Digital signing of the installer binary (the .EXE). That or shipping a > signed .MSI. > This is more important. It has to do with raising the confidence in > downloads and installs and is of immediate benefit. > > It *may* be the case that the installer binary .EXE already has room in the > file for a signature and it is simply not being used. The properties on the > binary .EXE are also not filled in for AOO 4.1.1 en-US. Those are the ones > that show a File description, File version, Product name, Product version, > Copyright, Language, etc. > > It might be worthwhile to see if the properties and signature can be injected > in the .EXE already. And if not, it may be possible to rebuild the .EXE, > since the bits are still around. They are what are extracted into a folder > which is then used for running setup. > > If feasible, this strikes me as a perfectly worthwhile exercise for > slip-streaming a signed binary of AOO 4.1.1 for Windows. As Andrea remarks, > It would also be a right-sized teething exercise for our learning how to work > through the signing process. > > I'm all for starting with the least that could possibly work, even though I > have no expertise on this. We had a signing mechanism in place for a long time and the reason why we have currently no digital signing is the lack of a certificate where we as project (PMC) or as representative the release manager have enough control. Anyway the new process should be used to sign the libs and other binary artifacts inside the install set and the installer binary itself. All this should be designed that it works more or less automatic or semi automatic using the new process. I hope the new signing mechanism can be used in a proper and efficient way for AOO. I am still no friend of this new process because we shift many many bits over the network and a local signing process on a dedicated machine looks more efficient and easier to me. But it is as it is and not under my control. Juergen > > - Dennis > > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Monday, December 8, 2014 15:08 > To: dev@openoffice.apache.org > Subject: Re: Budapest and thereafter. > > Marcus wrote: >> Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti: >>> We could actually do both, if you believe it makes sense: >>> - signed 4.1.1 (next Windows binaries only) by end of December >>> - 4.1.2 in January >> IMHO this doesn't make sense and would be just a waste of resources, >> when doing 2 releases in such a short time frame. >> But I would tend to do only the bigger release (4.1.2) - let's say in >> January/February. When ... > > Honestly, Infra would like (and they are right) that after asking for > years for digital signing, we actually use it. We can't put many > obstacles in front of it. So a long list of things that we must have > ready before that won't work. Signing Windows binaries will have to > happen, and users will benefit from it in terms of trust in OpenOffice. > > Assuming that more or less we can master the technology, distributing > the 4.1.1 signed binaries is not a huge feat for us (it would need > production of the new binaries and their upload to a new directory like > "windows-signed" and defaulting to "windows-signed" in the JavaScript in > the download page). It is far less than a release and at least it could > show that on this (new for OpenOffice) topic we are ready. > > In case I wasn't clear (and this is my fault for not summarizing the > Budapest talks correctly) signed binaries have high priority. One way is > to make a 4.1.2 release and sign it, and this requires going through the > whole process (no, it can't be a Windows-only release). Another way is > to ship a signed version of the existing 4.1.1 binaries as a "warm up" > for the moment when this will be integral part of the release process. > > 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 > - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Signing AOO 4.1.1 (was RE: Budapest and thereafter)
I don't know if this is helpful or not. I'm not in a position to check. Thinking out loud: There are two cases of signatures. 1. Digital signing of installable components, such as DLLs and such. This is also important but a second-order problem. 2. Digital signing of the installer binary (the .EXE). That or shipping a signed .MSI. This is more important. It has to do with raising the confidence in downloads and installs and is of immediate benefit. It *may* be the case that the installer binary .EXE already has room in the file for a signature and it is simply not being used. The properties on the binary .EXE are also not filled in for AOO 4.1.1 en-US. Those are the ones that show a File description, File version, Product name, Product version, Copyright, Language, etc. It might be worthwhile to see if the properties and signature can be injected in the .EXE already. And if not, it may be possible to rebuild the .EXE, since the bits are still around. They are what are extracted into a folder which is then used for running setup. If feasible, this strikes me as a perfectly worthwhile exercise for slip-streaming a signed binary of AOO 4.1.1 for Windows. As Andrea remarks, It would also be a right-sized teething exercise for our learning how to work through the signing process. I'm all for starting with the least that could possibly work, even though I have no expertise on this. - Dennis -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Monday, December 8, 2014 15:08 To: dev@openoffice.apache.org Subject: Re: Budapest and thereafter. Marcus wrote: > Am 12/08/2014 02:32 PM, schrieb Andrea Pescetti: >> We could actually do both, if you believe it makes sense: >> - signed 4.1.1 (next Windows binaries only) by end of December >> - 4.1.2 in January > IMHO this doesn't make sense and would be just a waste of resources, > when doing 2 releases in such a short time frame. > But I would tend to do only the bigger release (4.1.2) - let's say in > January/February. When ... Honestly, Infra would like (and they are right) that after asking for years for digital signing, we actually use it. We can't put many obstacles in front of it. So a long list of things that we must have ready before that won't work. Signing Windows binaries will have to happen, and users will benefit from it in terms of trust in OpenOffice. Assuming that more or less we can master the technology, distributing the 4.1.1 signed binaries is not a huge feat for us (it would need production of the new binaries and their upload to a new directory like "windows-signed" and defaulting to "windows-signed" in the JavaScript in the download page). It is far less than a release and at least it could show that on this (new for OpenOffice) topic we are ready. In case I wasn't clear (and this is my fault for not summarizing the Budapest talks correctly) signed binaries have high priority. One way is to make a 4.1.2 release and sign it, and this requires going through the whole process (no, it can't be a Windows-only release). Another way is to ship a signed version of the existing 4.1.1 binaries as a "warm up" for the moment when this will be integral part of the release process. 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
