www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Juergen Schmidt <jogischm...@gmail.com>
Subject Re: Official code signing certificate
Date Tue, 04 Jun 2013 20:34:06 GMT
Am Dienstag, 4. Juni 2013 um 21:52 schrieb Mark Thomas:
> On 24/05/2013 17:59, Scott Deboy wrote:
> > Logging Services has a simple requirement:
> > 
> > Have the Chainsaw build artifacts signed by a Java code signing cert
> > that is signed by a trusted/root CA so the jars can be downloaded via
> > WebStart without the user receiving a warning that the signed jars
> > aren't trusted.
> > 
> > The Chainsaw maven script supports signing jars - infra just needs to
> > point it to the cert.
> > 
> > I don't know whether or not an ASF-wide Java code signing cert makes
> > sense or a Logging Services-specific Java code signing cert makes
> > sense. I don't even know if it is possible to have TLP-specific Java
> > code signing certs. I defer to infra on that decision.
> > 
> > I believe the code signing service WRowe described will meet our
> > requirements. Hopefully infra can spend some time looking at the
> > service and see how it can meet their requirements.
> > 
> > Logging Services would like to be a guinea pig for the Java code
> > signing service WRowe described above. If there are additional
> > details needed by infra, we are happy to provide them.
> > 
> 
> 
> OK. That requirement is understood.
> 
> Code signing is on my TODO list after I have completed the current round
> of FreeBSD upgrades and after I have a cert arranged for
> *.openoffice.org. That means it is at least a month before I'll have the
> time this needs to progress it.
> 
> My (very) rough plan is to see if Verisign are still willing to offer us
> the free signing service and then work through how that might work.
> 
> The keys things for infra are:
> - minimising the risk that malicious code is signed
> - having a plan if to handle things if the worst does happen
> - ensure that the inputs to the signing process have been approved by
> the PMC signing
> - figure out what role infra needs to play in the signing process
> 
> I intend to use Tomcat to test this with as it has JARs and .exe's that
> can be signed and I have the necessary commit privs to modify the build
> process if required.
> 
> If you want to help progress this then reaching out to Bill and
> re-connecting with Verisign would be a useful thing to do. In an ideal
> world if you can line things up so I can get what I need (service docs,
> how to register for the service, how to use the service, etc.) to start
> testing / investigating this that would be great.
> 
Hi Mark,

I am still available to provide more info regarding the requirements of OpenOffice. As mentioned
earlier in a discussion related to code signing, we have a multistep signing process in place
during the build process and when we gave the cert under full control. This has to adapted
in a way that is appropriate to the new process. I believe the OpenOffice requirements are
the mist complex ones and O hope we can find a working and what's more important secure and
save workflow that satisfy all requirements.

Regards
Juergen
> 
> Mark
> 
> > 
> > Thanks,
> > 
> > Scott
> > 
> > On 4/12/13, sebb <sebbaz@gmail.com> wrote:
> > > You are now in http://wiki.apache.org/general/ContributorsGroup
> > > 
> > > 
> > > On 12 April 2013 17:32, William A. Rowe Jr. <wrowe@rowe-clan.net> wrote:
> > > 
> > > > On Fri, 12 Apr 2013 10:47:29 -0500
> > > > "William A. Rowe Jr." <wrowe@rowe-clan.net> wrote:
> > > > 
> > > > > On Tue, 26 Mar 2013 00:56:06 +0200
> > > > > Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> > > > > 
> > > > > > Can you write this all down somewhere? A wiki page maybe
> > > > > 
> > > > > http://wiki.apache.org/general/ASFCodeSigning
> > > > 
> > > > Could one of the page editors please grant WilliamARoweJr some
> > > > karma? I'll document the first-draft approach and the Symantec
> > > > service-based approach.
> > > > 
> > > 
> > > 
> > 
> > 
> 
> 
> 



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message