Here's my suggestion for addressing this: a non-profit company is registered in the States (e.g. 'CoApp Software Foundation', akin to Apache Software Foundation, Python Software Foundation, etc). A VeriSign code-signing certificate is purchased, and we establish a process for building and signing CoApp-compliant apps on behalf of the open source projects (assuming their release meets the pre-requisites we define in the aforementioned process).
This is analogous to the process Apple makes you follow in order to get your iPhone/Pad/Touch apps on AppStore (upload your source and they build it from scratch and distribute it). We could leverage Snakebite (www.snakebite.org<http://www.snakebite.org>) for doing the builds in a controlled manner. Thoughts? Trent. ________________________________ From: coapp-developers-bounces+tnelson=onresolve....@lists.launchpad.net [coapp-developers-bounces+tnelson=onresolve....@lists.launchpad.net] On Behalf Of Ivan Meredith [[email protected]] Sent: 13 April 2010 09:32 To: Adam Baxter Cc: [email protected] Subject: Re: [Coapp-developers] Let's talk about libraries Is there no way around this? I know for the general usage, a package maintained by coapp would be signed by coapps cert. But various third parties host there own repos. For debian theres : google-chrome, wine, and others I cant remember. Will they have to use official channels to get it signed (or buy a cert) ? (Nightly) Development builds in project repositories are useful to some. On Tue, Apr 13, 2010 at 8:12 PM, Adam Baxter <[email protected]<mailto:[email protected]>> wrote: >In order to use WinSXS however, all binaries must be signed with an >Authenticode code-signing certificate, from a reputable CA (certifying >authority). This is automatically a major roadblock for many open source projects. On Tue, Apr 13, 2010 at 3:49 AM, Garrett Serack <[email protected]<mailto:[email protected]>> wrote: Since I’ve been jumping all around the map on answering questions, I wanted to first jump into the heart of what CoApp really fixes, and we’ll work our way out from there. Libraries (static or dynamic) are the heart and soul of pretty much all software—and open source is no exception. If code didn’t depend on no other code, then packages would be insanely trivial to engineer, we’d just zip up the files and that would be it. However, since this isn’t the case, we need to understand what Libraries mean to us, and what we need to ensure to make everything end up shiny. What CoApp will address: - There must be a common method to access a Shared Library, in a logical consistent fashion - A particular version of a library (with a specific binary ABI) must be upgradable to a new compatible version without having to adjust a currently installed application - Multiple versions of a library (with potentially different binary ABIs) must be able to be present at the same time - Multiple compilers must be supported--that is, multiple copies of the same library, the same version and the same ABI, but reliance on a different compiler (and CRT runtime) - Libraries must be installed and upgraded independently of an application - An application must be able to override a system default version of a library if necessary - Shared libraries should always be packaged with their relevant import libraries (.lib) and header files (.h) files Luckily, Windows provides us a way to do most of that without much difficulty—provided you have tools to automate that. WinSXS (Windows Side-by-side) technology allows us to install multiple versions of libraries, each tagged with a version (Major.Minor.Revision.Build) , and allows us to build ‘policy’ files that direct programs to use the correct version. We use manifests with the applications to tell it what version (Major.Minor) it requires, and the policy files direct the EXE to the best match (most of the time, the most recent version in a given Major.Minor set. Consistency of the Major.Minor versions indicates a binary ABI compatibility. Changing the Major or Minor numbers in effect declares that binary compatibility may not be guaranteed (however, policies can be written to forward older versions if the author claims binary compatibility is still present) In order to use WinSXS however, all binaries must be signed with an Authenticode code-signing certificate, from a reputable CA (certifying authority). This signing requirement actually turns out to be the key to supporting multiple compilers at the same time—a publisher can use multiple certificates, reserving an individual certificate’s use to a particular compiler. (so CoApp as a publisher will have certificates for signing packages for both VC9 and VC10 binaries) In order for the consuming application to specify what library it is looking for, its manifest lists the certificate thumbprint, the name of the library and the version. <http://fearthecowboy.com/> Garrett Serack | Microsoft's Open Source Software Developer | Microsoft Corporation Office:(425)706-7939 email/messenger: [email protected]<mailto:[email protected]> blog: http://fearthecowboy.com<http://fearthecowboy.com/> twitter: @fearthecowboy<http://twitter.com/fearthecowboy> I don't make the software you use; I make the software you use better on Windows. _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers> Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-developers> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected]<mailto:[email protected]> Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
