coapp-developers team mailing list archive

[Ivan Meredith <ivan@xxxxxxxxxxx>]

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.
>>
>>
>>
>>
>>
>> [image: Description: fearthecowboy] <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
>
>