← Back to team overview

coapp-developers team mailing list archive

Re: Codesigning for the masses.

 

A decision was made also to support self created certificates and provide
some sort of notification to the user that the certificate isn't from a CA.
On Jan 5, 2012 9:16 AM, "Garrett Serack" <garretts@xxxxxxxxxxxxx> wrote:

>  Not Quite.
>
>  Yes, Unsigned packages can not be made. That has always been a line I
> was unwilling to cross, as digital signing is a key critical factor.
>
>  But, you can always get a certificate from a CA (for open source, free,
> from Certum) or from one of the other CAs, and publish software with that.
>
>  What I'm proposing is that we insert the CoApp project as another CA to
> get around the limitations of limited CA choice and pay-for-service where
> its not required.
>
>  We can't just use GPG ... while we can create hashes, that doesn't work
> with the digital signing infrastructure already built into Windows.
> Authenticode digital signing is the only solution.
>
>  G
>
>  ------------------------------
> *From:* Pau Garcia i Quiles [pgquiles@xxxxxxxxxxx]
> *Sent:* Thursday, January 05, 2012 1:19 AM
> *To:* Garrett Serack
> *Cc:* coapp-developers@xxxxxxxxxxxxxxxxxxx
> *Subject:* Re: [Coapp-developers] Codesigning for the masses.
>
>  Hi,
>
> IIUC, that means unsigned packages, or packages that are not signed with a
> certificate blessed by you cannot be installed. I. e. alternate CoApp
> repositories cannot exist?
>
> Why not doing something as simple as Debian and others do? Just GPG sign
> the packages, have a keyring package with is installed in the base
> installation (and you can update without needing to update CoApp itself)
> and show the infamous "this certificate is not valid" warning screen on
> installation. That would still allow for unsigned packages, alternate
> repositories, etc.
>
>
>
> On Wed, Jan 4, 2012 at 8:15 PM, Garrett Serack <garretts@xxxxxxxxxxxxx>wrote:
>
>>  I’ve been thinking this over for a bit, and I’ve come to a bit of a
>> revelation.****
>>
>> ** **
>>
>> I want to issue code-signing certificates to individuals so they can
>> publish their own open source packages.****
>>
>> ** **
>>
>> I’ve got a longer-term goal of creating a web-of-trust layer on top of
>> the existing Authenticode digital signing system, but that’s really going
>> to take forever, and I’m now of the opinion that doing something useful now
>> is better than doing something perfect later.****
>>
>> ** **
>>
>> *What I’m proposing*
>>
>> ** **
>>
>> We create a root certificate that can be used as a root to generate
>> code-signing certificates.****
>>
>> ** **
>>
>> Include this root certificate with CoApp itself, and install it into the
>> *root certificate authorities* at install time.****
>>
>> ** **
>>
>> For CoApp contributors that have signed the CoApp CLA, I issue a *
>> personal* code-signing certificate to each person who wishes to publish
>> their own packages.****
>>
>> ** **
>>
>> Using CoApp’s *SimpleSigner* and *Autopackage* tools, they will be able
>> create their own packages, and be able to upload them to the CoApp.org
>> server where once instantly validated, they get added to the
>> http://coapp.org/feed package feed.****
>>
>> ** **
>>
>> We would need to have a certificate revocation list published on
>> http://coapp.org/ and embedded in the root certificate so that we could
>> revoke a certificate if need be.****
>>
>> ** **
>>
>> We’d keep the certificate validity down to 6 months between renewals.****
>>
>> ** **
>>
>> In the event someone went insane and stopped playing nice, we revoke
>> their certificate, and publicly flog them.****
>>
>> ** **
>>
>> Essentially, this is a way for me to delegate publishing binaries of
>> software to individuals who participate in the project. ****
>>
>> ** **
>>
>> We’re still in Beta, so I think this is the best time to try this, and
>> work out the kinks before we hit *1.0 Release.*****
>>
>> ** **
>>
>> In the short run, I’ll manually manage the process of handing out
>> certificates to individuals.****
>>
>> ** **
>>
>> *Worst Case Scenario*
>>
>> If this turns out to be a really stupid idea for some reason, we can
>> easily remove the CoApp root certificate, thereby invalidating all the
>> certs.****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *What do you think? I want feedback!*
>>
>> * *
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> [image: Description: Description: Description: fearthecowboy]<http://fearthecowboy.com/>
>> ****
>>
>> *Garrett* *Serack* | Microsoft Senior 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
>> Post to     : coapp-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~coapp-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
> _______________________________________________
> 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
>
>

GIF image


Follow ups

References