On Tuesday, December 9, 2014, Rob Weir <[email protected]> wrote: > On Mon, Dec 8, 2014 at 9:29 PM, Dennis E. Hamilton > <[email protected] <javascript:;>> 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:[email protected] <javascript:;>] > > Sent: Monday, December 8, 2014 15:08 > > To: [email protected] <javascript:;> > > 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: [email protected] > <javascript:;> > > For additional commands, e-mail: [email protected] > <javascript:;> > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > <javascript:;> > > For additional commands, e-mail: [email protected] > <javascript:;> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <javascript:;> > For additional commands, e-mail: [email protected] > <javascript:;> > > -- Sent from My iPad, sorry for any misspellings.
