I concur with Rob's analysis here (quoted below). It occurs to me that there is another spanner in the works. This will impact whatever the signing process is.
Namely: Not only does the installer need to be signed, but those *installed* components (e.g., .exe and .dll files) that can bear embedded, OS-recognized signatures need to be signed if products of the build from source. In the case of bundled third-party components that are installed as-is, they may need to be signed by their originator as well. This is part of the authenticity provision. It has an important provision in determining whether or not a component has been altered or replaced after installation. (In the case of drivers and other components, the OS may be fussier than that.) This is also important if component-level replacement by patches is introduced. I don't know that all of this has to be swallowed at once. I is going to be a factor in the future and it would be good to take preparatory action. I expect that the bar will be raised on extensions too, and that might be handled by upgrading .oxt to use ODF 1.2 packaging, relying on the digital signature provisions that are already there for packages and special components such as scripts and macros. - Dennis -----Original Message----- From: Rob Weir [mailto:[email protected]] Sent: Sunday, August 26, 2012 13:47 To: [email protected] Subject: Re: svn commit: r1377482 - /incubator/ooo/trunk/main/external_deps.lst [ ... ] My point is that if we seek to have build-bot automated signed binaries it is entirely foreseeable that what we're proposing to do with 3rd party dependencies will also be out of policy, due to the security concerns. To do this we'll need to do more than just link to random sites on the web for dependencies. [ ... ] Look at Andre's note from August 3rd. First locations searched for dependencies is the original website where it is hosted. Then it checks Apache Extras. Then it checks SVN. Taking SVN out of the loop solves one issue. But we still have the other issue -- I think Dennis groks this as well -- that our primary search location is less secure than the alternatives. [ ... ], two relatively simple improvements: 1) Search Apache Extras first or 2) Have the current script verify a detached signature rather than relying on MD5 hashes [ ... ]
