coapp-developers team mailing list archive
-
coapp-developers team
-
Mailing list archive
-
Message #01227
Re: Codesigning for the masses.
Yeah. Eventually.
G
________________________________
From: Eric Schultz [wwahammy@xxxxxxxxx]
Sent: Thursday, January 05, 2012 7:20 AM
To: Garrett Serack
Cc: Pau Garcia i Quiles; coapp-developers@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Coapp-developers] 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<mailto: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<mailto:pgquiles@xxxxxxxxxxx>]
Sent: Thursday, January 05, 2012 1:19 AM
To: Garrett Serack
Cc: coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto: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<mailto: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!
[Description: Description: Description: fearthecowboy]<http://fearthecowboy.com/>
Garrett Serack | Microsoft Senior Open Source Software Developer | Microsoft Corporation
Office:(425)706-7939<tel:%28425%29706-7939> email/messenger: garretts@xxxxxxxxxxxxx<mailto:garretts@xxxxxxxxxxxxx>
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 : coapp-developers@xxxxxxxxxxxxxxxxxxx<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~coapp-developers<https://launchpad.net/%7Ecoapp-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<mailto:coapp-developers@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~coapp-developers
More help : https://help.launchpad.net/ListHelp
References