coapp-developers team mailing list archive

[Pau Garcia i Quiles <pgquiles@xxxxxxxxxxx>]

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)