> > > 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). >
I think its a fairly good idea, but I still don't think packages should *have* to be signed by the 'CoApp Software Foundation'. If they *have* to be signed by a specific CA, then I guess they do have to be signed by CoApp, or at least someone will need to have there own certificate. But thats not ideal in my opinion. I kinda just realized that only the WinSXS things need to be signed don't they? And if a developer was playing around with packaging something, it would still be possible to install a library that didn't use WinSXS (sorry I don't really understand exactly how WinSXS is leveraged, so I'm probably using the term a bit wrong). I still think ideally it would be good if signing was not a requirement to get WinSXS to work, but I guess you can't just "turn off" the requirement. On Wed, Apr 14, 2010 at 12:09 AM, Trent Nelson <[email protected]>wrote: > 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) for doing the builds in a > controlled manner. > > Thoughts? > > Trent. > > ------------------------------ > *From:* > coapp-developers-bounces+tnelson=onresolve....@lists.launchpad.net[coapp-developers-bounces+tnelson= > [email protected]] 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]>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] >> > 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] >>> >>> *blog*: 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] >>> 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] >> 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
