coapp-developers team mailing list archive

[Ivan Meredith <ivan@xxxxxxxxxxx>]

>
>
> 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 <tnelson@xxxxxxxxxxxxx>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.com@xxxxxxxxxxxxxxxxxxx[coapp-developers-bounces+tnelson=
> onresolve.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Ivan Meredith [
> ivan@xxxxxxxxxxx]
> *Sent:* 13 April 2010 09:32
> *To:* Adam Baxter
> *Cc:* coapp-developers@xxxxxxxxxxxxxxxxxxx
> *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 <voltagex@xxxxxxxxxxxx>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 <garretts@xxxxxxxxxxxxx
>> > 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*: garretts@xxxxxxxxxxxxx
>>>
>>> *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     : coapp-developers@xxxxxxxxxxxxxxxxxxx
>>> 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     : coapp-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~coapp-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>