Trent sees the big picture nicely :D AB>> Is there no way around this? I know for the general usage, a package maintained by coapp would be signed by coapps cert. No, we really do want *everything* signed. This halts so many problems, and it's not very difficult to make work on a large scale for a lot of people.
AB>>But various third parties host there own repos. Will they have to use official channels to get it signed (or buy a cert) ? Yes, all publishers will have to have their own certificates for signing binaries and packages. It's really no harder than acquiring an SSL cert. Which isn't hard at all. >From the wiki: Publishers Publishers create packages for end-users and developers to download. The CoApp project will be one publisher of packages, and other open source projects have expressed interest for publishing packages themselves. It is worth noting, that the publisher of a software package does not need to be the author, and it is perfectly permissible for multiple publishers to publish a package built from the same source code (although redundant). The Packages will not collide, as each package is digitally signed by the publisher. The CoApp project will initially adopt a number of projects (see below), and continue to support them until/unless the author decides to publish CoApp-compatible packages themselves. I have committed to ensuring that access to certificates is not a problem for publishing open source software. I have a few different plans handling diverse scenarios, but rest assured that Yes, signed binaries are an absolute requirement, and Yes, everyone will be able to find a path to publish their software. Code Signing will virtually eliminate the threat of malware in CoApp packages. As well, one of the reasons that this is a Codeplex Foundation project is precisely because we can easily acquire code signing certificates. Packages don't have to be signed by CoApp's certificate or necessarily the same CA as CoApp. But they will have to be signed. Gonna do a blog post about this. Garrett Serack | Open Source Software Developer | Microsoft Corporation I don't make the software you use; I make the software you use better on Windows. From: coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net [mailto:coapp-developers-bounces+garretts=microsoft....@lists.launchpad.net] On Behalf Of Ivan Meredith Sent: Tuesday, April 13, 2010 5:46 AM To: Trent Nelson Cc: [email protected] Subject: Re: [Coapp-developers] Let's talk about libraries 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]<mailto:[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<http://www.snakebite.org>) for doing the builds in a controlled manner. Thoughts? Trent. ________________________________ From: coapp-developers-bounces+tnelson=onresolve.com<http://onresolve.com>@lists.launchpad.net<http://lists.launchpad.net> [coapp-developers-bounces+tnelson=onresolve.com<http://onresolve.com>@lists.launchpad.net<http://lists.launchpad.net>] On Behalf Of Ivan Meredith [[email protected]<mailto:[email protected]>] Sent: 13 April 2010 09:32 To: Adam Baxter Cc: [email protected]<mailto:[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. 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
